It seems that Qt devs finally showed interest in this problem. See QTBUG-84179
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
May 16 2020
Aug 21 2019
MouseArea.pressAndHold runs based on the synthesised left press event, I don't see anything in your code which would prevent a conflict there.
Same for any widget code that uses a current QTapAndHoldGesture
In T10783#196060, @ngraham wrote:IIRC the objection was that making press-and-hold always mean right-click at the toolkit level could interfere with apps that want to re-implement the press-and-hold behavior for some other behavior. For example a lot of Android apps use press-and-hold to mean "make this list/view editable".
Personally I think a consistent behavior is more important, but I understand that it is a concern.
No, we need exactly right click events. They are too important for many apps. For instance, how will we mark the cells in KMines without right click event? I backported my patch on 5.12 in order to replace native Qt version under Kubuntu and now I can successfully mark and unmark the cells.
Aug 19 2019
I made a patch which adds ability to emulate right click for Qt widgets which do not accepted touch events, but Qt devs say "such a feature should live in the platform itself (not in Qt), e.g. at the driver level or similar". So we have a strange situation when libinput (driver devs) have no plans to add right-click emulation to libinput, because it is the wrong layer of the stack and KWin devs think so, but Qt devs believe that it shall by done somewhere on this layer.
Aug 18 2019
Aug 14 2019
In D23146#511783, @ngraham wrote:Hmm, can you explain why you think this is an improvement? To me it seems sensible enough to warn people that closing a tab (even if it's the only tab) will kill the running program.
Aug 7 2019
Ping?
Jul 29 2019
In D22420#503317, @elvisangelaccio wrote:I'd still like to understand what happend at the change in 4e40fe810d324.
@ngraham Any idea?
Jul 28 2019
@elvisangelaccio, you have forgotten or I did not say clear enough that it is the previous cosmetic cosmetic version(Diff 61904) that was correct! Read my remark again in the revision conversation, please. @hein did not respond and I cannot say even if this one is fully correct for Korean. The one line solution does groupping of some Cyrillic symbols, which cannot be grouped toggether(aleast in Russian dictionary)
This was my fall. Sorry again for it.Oh, I see.
So should we revert this commit or are you going to post another patch on top of it?
@elvisangelaccio, you have forgotten or I did not say clear enough that it is the previous cosmetic cosmetic version(Diff 61904) that was correct! Read my remark again in the revision conversation, please. @hein did not respond and I cannot say even if this one is fully correct for Korean. The one line solution does groupping of some Cyrillic symbols, which cannot be grouped toggether(aleast in Russian dictionary)
This was my fall. Sorry again for it.
Jul 27 2019
Ping!
Jul 21 2019
Friendly ping!
In D22303#499562, @elvisangelaccio wrote:In D22303#497268, @AndreyYashkin wrote:Previous Diff 61904 was correct.
Did that work also with Korean?
Jul 18 2019
I am sorry. I was so happy with this simple solution that forgot about one impornat aspect which is different from from language to language. If in a German dictionary 'O' and 'Ö' would be in the same group, in Russian 'Е' and 'Ё' or 'И' and 'Й' can never be together like new patch does. Probably, it is applicable to Korean, but in doesen't solve problem for all languages.
I used @hein idea to apply normalization which is implemented in unicode. Now it seems to be the final solution without working with particular writing system individually.
Jul 17 2019
Fixed brackets and spaces style
Jul 16 2019
In D22386#495914, @anthonyfieroni wrote:It does not look correct either, the problem is that the focus on location bar is delayed and setActive(false) isn't applied, this is workaround. But we have problems on that before, exactly that part with focusIn on location bar. You should correct there but it can break something other.
Jul 15 2019
Equivalent solution
In D22420#495467, @elvisangelaccio wrote:This issue was supposed to be fixed by commit 4e40fe810d324 but it seems it got reintroduced in the past months.
Could you try to git bisect it to figure out when this happend?
Jul 12 2019
Added braces
Jul 11 2019
I've deleted the else repeating and added warning about founded wrong behavior for Z group corner case.
Solving this requires another method for separation Latin and non Latin characters.
Jul 10 2019
Jul 8 2019
In D22303#491971, @elvisangelaccio wrote:Thanks for the patch!
Given that the correctness of this code depends on the locale, I'm not confident we won't break some corner cases.
Ideally we'd need more unit tests in KFileItemModelTest::testNameRoleGroups(), but I understand that's a lot to ask.@cfeck in the bug report suggested to add more letters ranges. @AndreyYashkin Did you try that?
Jul 7 2019
In D22303#491930, @ngraham wrote:If you don't have a contributor account, someone who does needs to land the patch on your behalf. Don't worry, it'll happen! I just want Dolphin's maintainer @elvisangelaccio to give his OK first.
In D22303#491771, @ngraham wrote:Thanks, very nice first patch! This looks like the correct fix to me, and doesn't break grouping with the Latin alphabet or any of the unit tests. And you even used arc to submit the patch, so I don't have to ask for your email address. All in all, solid work!