(I got a suggestion to just file a new bug on this, https://bugs.kde.org/show_bug.cgi?id=341959#c46) I installed khotkeys5-5.4.90git~20150822T211938~c0484e4-1.1.x86_64 kglobalaccel5-5.15.0git.20151005T231957~bf71e53-2.1.x86_64 from my distro's packages (Opensuse). It looks like 2 things aren't working. (1) Triggers that use "Ctrl" (2) Actions that have "Shift-ed" keys It looks like problem is contained in khotkeys, since global accels in general work (https://bugs.kde.org/show_bug.cgi?id=341959#c42) At KDE's "System Settings" > "Shortcuts" > "Custom Shortcuts" > "Configure Input Actions settings" first, anytime you use the 'Ctrl' key there's no output Action = t:e:s:t Trigger Output ============ =========== Ctrl+T (none) Alt+T test Meta+T test Ctrl+Alt+T (none) Meta+Ctrl+T (none) Meta+Alt+T test Meta+Ctrl+Alt+T (none) Second, "Shifted" keys (for example 'Shift+2' == "@") don't work Action = t:e:s:t:Shift+2 Trigger Output ============ =========== Ctrl+T (none) Alt+T test Meta+T test Ctrl+Alt+T (none) Meta+Ctrl+T (none) Meta+Alt+T test Meta+Ctrl+Alt+T (none) If you test the "kcmshell5 keys", it works. If in "Global Keyboard Shortcuts" I select KDE component = krunner and change "Run command" from Global = Default: Alt+Space (which works) to Global = Custom: Meta+Ctrl+Alt+T it works OK using "Meta+Ctrl+Alt+T", and launches 'krunner'. Looking for khotkeys bugs https://bugs.kde.org/buglist.cgi?product=khotkeys&component=general&resolution=---&list_id=1301814 There's a long list that suggests the khotkeys component is a) severely broken b) virtually unmaintained I sure don't know why it's different than the kglobalaccel stuff. To me they seem pretty much linked together from a user perspective. It's for sure working on older KDE4 setups, though. So it's not a new thing. It was working then broken. Does that make it a "regression"? It doesn't look like anyone decided to stop having it in KDE since it's obviously still "in there". I know I use it a lot. From that list it looks like others do too. Reproducible: Always
Either (ctrl shortcut or shift modifier) works perfectly when seding the input to Qt4 or gtk+ clients (didn't test gtk3), but reproduclibly fails on Qt5 clients, ie. Qt5 handling of XSendEvent is broken. Can you confirm this?
Iiuc, Firefox is a gtk+ client. Konsole is a Qt5 client Not sure what's still a Qt4 app. For Trigger = Ctrl+T Action = "t:e:s:t:Shift+2" test output is app output ----------- ----------- Konsole (none) Firefox test@ So you're correct, Qt5 issue. I noitced one additional behavior. If I have Trigger = Ctrl+T Action = "t:e:s:t" and output in Firefox is "test", then change to Trigger = Ctrl+T Action = "t:e:s:t:Shift+2" and just click 'Apply', it does NOT work in Firefox. I still get just "test" as output. But if I unselect the ConfigureInputAction in the Name column click Apply REselect the ConfigureInputAction in the Name column click Apply now in Firefox I get the "test@" output. In Konsole, still nothing.
Just for info I changed to Action = "t:e:s:t:Shift+~:Shift+1:Shift+2:Shift+3:Shift+4:Shift+5:Shift+6:Shift+7:Shift+8:Shift+9:Shift+0:Shift+-:Shift+=" unselect Name item Click Apply REselect Name item Click Apply In Firefox output is test~!@#$%^&*()_+
Thanks for the confirmation, I'll see whether I can find a present Qt5 bug on this config editing /is/ broken (badly) https://git.reviewboard.kde.org/r/125630/ https://git.reviewboard.kde.org/r/125607/
*** Bug 349746 has been marked as a duplicate of this bug. ***
This has been brought to the Qt mailing list before: http://lists.qt-project.org/pipermail/interest/2014-June/012718.html
I see that you marked this as "RESOLVED UPSTREAM". Did you also refile the bug somewhere? Since this was apparently "brought to the Qt mailing list before", but was eventually just ignored or dropped, what should be changed in the process so that it's not overlooked again? Is there something I'm supposed to do now? It'd be good to not let this just get dropped again. Also, there's been a slight change in behavior. After recent package updates to kglobalaccel5-5.16.0git.20151010T101131~5b654f2-1.1.x86_64 khotkeys5-5.4.90git~20151012T154718~4747599-2.1.x86_64 Using Trigger = Ctrl+T Action = "t:e:s:t:Shift+~:Shift+1:Shift+2:Shift+3:Shift+4:Shift+5:Shift+6:Shift+7:Shift+8:Shift+9:Shift+0:Shift+-:Shift+=" Now output is app type output ---------- -------------------- gtk+ test~!@#$%^&*()_+ Qt5 90-=
With ctrl+t i get "+190-0" - with ctrl+meta+t i (still) get nothing. khotkeys was fixed to not crash w/o xcb and to not override its config by a dated variant, that's all I know. "resolved upstream" only means "totally not our problem" (though the accurate value would have been "invalid", because the problem is nowhere in the khotkeys chain, I didn't want to piss you off, though ;-) I've yet not found a Qt bug about mishandling of synthetic (keyboard) events - but that's a HUGE problem so there should be one ;-)
I understand, thanks. I'm not pissed off at all. Just concerned. From what little I've been able to actually understand "this" shortcuts stuff has been bouncing around between KDE & Qt groups for awhile. Even as just a user I get it, but hope 'someone out there' also gets that "we" just see KDE. Previous versions and current versions. And that to us these separations often seem a way to kick the can down the road. I'm just hoping it's possible to dig our heels in on this one and actually get eyes and skills on it! Since I don't know better yet I'll just sit in here until you or someone else instructs a good place to move. Thanks.
(In reply to JohnA from comment #9) > From what little I've been able to actually understand "this" shortcuts > stuff has been bouncing around between KDE & Qt groups for awhile. This is actually between Qt and X11 - the other bug fails on xvkbd and the mailing list is about (i think a virtual keyboard) in lyx. I fear Qt5 moved focus to libinput and therefore on hardware states of modifiers, thus breaking logic events - in that case it will simply be impossible to send "unreal" input to Qt5; we'll have to operate on xtest to fake input - and first of all "release" everything the user has currently pressed (pot. causing false action or out-of-sync conditions inside the client) I gave up searching for a Qt bug (it's either not reported or has been closed) and filed https://bugreports.qt.io/browse/QTBUG-48795
I tested also with Trigger = Meta+Ctrl+Alt+T Output is still app type output ---------- -------------------- gtk+ test~!@#$%^&*()_+ Qt5 90-= I started searching around for mentions of "Meta+Ctrl+Alt", "Shift+", "KDE" & "Qt" I found this related couple of bugs https://bugreports.qt.io/browse/QTBUG-24304 https://bugs.kde.org/show_bug.cgi?id=284905 that go back a few years to Qt4 > kde4-config -v > Qt: 4.7.4 > KDE Development Platform: 4.7.2 (4.7.2) "release 9" > kde4-config: 1.0 Not exactly the same because it has something to do with passwords too but it does mention same kind of problems with the Triggers and shortcuts that don't work. It looks like there were actual Qt devs discussing some of that but in the end those bugs got basically ignored too But something must have gotten fixed in Qt4 back then because on a current box I have kde4-config -v Qt: 4.8.7 KDE Development Platform: 4.14.9 kde4-config: 1.0 And all the shortcuts work work in both gtk+ and Qt4 apps on that box. I don't know if that tells you anything about the Qt5 situation now. Maybe just the names of the developers or the area to look at.
Correction. With Trigger = Meta+Ctrl+Alt+T Output is app type output ---------- -------------------- gtk+ test~!@#$%^&*()_+ Qt5 190-=
Just hoping maybe that the last dev (both KDE & Qt it looks like) that commented on one of those bugs, Frederik Gladhorn, maybe has some idea where in Qt to put this, or better even about how to fix it. So I cc'd him here. @frederik Any ideas maybe where to go with this Qt5 issue?
I just read this: http://blog.martin-graesslin.com/blog/2015/10/some-thoughts-on-the-quality-of-plasma-5/ "Not ported featured There are a few more features which just didn’t make it to the new release. In many cases that’s because of the features do not have a maintainer. Examples for this are KHotkeys and the application menu. In both cases the port was not trivial due to changes in the underlying infrastructure, so we couldn’t manage it with our limited resources." I just don't know what if anything to make of that :-/
Nothing. I think the major lack is mouse gestures. Otherwise we're now running after bugs in khotkeys are we not? :-P Ultimately, it doesn't affect *this* bug since that's a problem in the Qt5 clients - it affects khotkeys from KDE4 and even KDE3 just as much.
> Otherwise we're now running after bugs in khotkeys are we not? TBH I don't know if it's khotkeys or Qt. > since that's a problem in the Qt5 clients - it affects khotkeys from KDE4 and even KDE3 just as much. The shortcuts I use on the KDE4 system I have work just fine. That's because kde4-config --version Qt: 4.8.7 <=================== v4, not v5? KDE Development Platform: 4.14.9 kde4-config: 1.0
It's a bug in Qt5 and if you try to send input to any Qt5 client from KDE4 khotkeys, it will still fail. I know that, because it also fails for "xvkbd -sendevent", which isn't KDE at all ;-) This is *not* about khotkeys or kglobalaccel or anything in KDE - Qt5 clients simply misinterpret synthetic events, no matter where they stem from.
Just for reference for anyone still interested, upstream doesn't consider KDE regression a priority >> The real question is then, why does a regression that affects one of the >> most popular Qt programs out there (KDE Plasma) get such a low priority? > > Because it is an uncommon case. Corner-case issues don't get high priority. Apparently breaking users' long-established functionality is a "corner case". Years of reports only gets more years to come. Thanks for the help. I quit. Ordered a Mac.
(In reply to i1387094 from comment #18) > >> The real question is then, why does a regression that affects one of the > >> most popular Qt programs out there (KDE Plasma) get such a low priority? > > > > Because it is an uncommon case. Corner-case issues don't get high priority. Where exactly is the quote from? It's dead wrong. If Qt declares "no more synthetic event handling", that's one thing and the khotkeys feature will have to resort to xtest, BUT that's not the case! Qt handles sythetic events *WRONGLY* - what can result in random input. That's not a corner case at all, but actually a severe issue. In or out is ok, broken is certainly not. => Where is that quote from? (It's not on the Qt bug, afaics)
> => Where is that quote from? (It's not on the Qt bug, afaics) From Thiago Macieira @ http://lists.qt-project.org/pipermail/development/2015-November/023807.html
http://forum.kde.org/viewtopic.php?f=224&t=129458&p=346282 It sounds like this bug might be the cause for that problem as well. If so, I can confirm its existence. I'll wait for the fix to reach openSUSE Tumbleweed and see if it works.
(In reply to Mircea Kitsune from comment #21) > It sounds like this bug might be the cause for that problem as well. *this* bug is a bug in Qt ;-) I believe the dolphin problem is related to the Qt bug, since dragging grabs the mouse, so the receiving window will miss the modifier when the drag enters the window and it apparently does not look at the modifier on the release. => https://bugreports.qt.io/browse/QTBUG-49645 I *assume* the two Qt bugs are related, but "your" bug is not actually related to *this* bug (DnD ./. xsendevent)
(In reply to i1387094 from comment #20) > > => Where is that quote from? (It's not on the Qt bug, afaics) > From Thiago Macieira @ > http://lists.qt-project.org/pipermail/development/2015-November/023807.html Ok, but this is an explanation on "why is this P3" - and after you kinda annoyed Thiago (with your bumps to the bug and the not so prudent tone in that ML thread - you had been informed that it's correctly assigned to Gatis, what's also prominently stated on the bug, ie. you were coming around like "is it yet fixed?" "is it yet fixed?" "is it yet fixed?" "is it yet fixed?") He didn't eat you, so you made a good cut. Be happy that you're still alive and didn't wet yourself :-P Also P3 is "Somewhat important" ie. mediocre, not low (P4) - the assignment is ok, P2/1/0 have different qualities.
> "is it yet fixed?" "is it yet fixed?" "is it yet fixed?" "is it yet fixed?") > > He didn't eat you, so you made a good cut. Be happy that you're still alive > and didn't wet yourself :-P Really that's what you get out of trying to help? What are you, 14 yrs old? Well screw you too, and good riddance to KDE et al. Outa here.
(In reply to i1387094 from comment #24) > Really that's what you get out of trying to help? What are you, 14 yrs old? I've grown to an age where I learned that bullying and nagging the ones you rely on is not the best possible approach to get what you want. And that it's spelled "years". I must say that I do not consider your actions on the Qt bug any helpful at all, sorry. You *did* behave like that and Thiago can become quite direct if you go too far.
What the heck? This is a bug report, not Youtube or Tumblr people. Sorry... but let's just please keep typical internet attitudes out of here at least.
*** Bug 373956 has been marked as a duplicate of this bug. ***