Bug 341959

I might add that I'm using an Icelandic (is) keyboard layout.

Still valid in 5.1.2. This is not only an issue for meta+shift+<number>, but all shortcuts involving shift+number. So ctrl+shift+<number> and alt+shift+<number> also don't work.

might be just a problem with the configuration widget. Where are you trying to configure this?

Using the "Global Keyboard Shortcuts - KDE Control Module" selecting the "kwin" component.

The result in the .config/kglobalshortcutsrc looks like this (In the KDE4 kglobalshortcutsrc it looks exactly the same):
Window to Desktop 2=Meta+@,none,Window to Desktop 2
Window to Desktop 3=Meta+#,none,Window to Desktop 3

reassigning to xmlgui as it's using KShortcutsEditor

*** Bug 345020 has been marked as a duplicate of this bug. ***

*** Bug 345143 has been marked as a duplicate of this bug. ***

*** Bug 345130 has been marked as a duplicate of this bug. ***

bug #345130has a patch proposal

*** Bug 343626 has been marked as a duplicate of this bug. ***

The bug is in kglobalaccel. And I have a patch in #345130 that fixes this for me. Please review. Thanks

(In reply to yshuiv7 from comment #11)
> The bug is in kglobalaccel. And I have a patch in #345130 that fixes this
> for me. Please review. Thanks

I don't know why, but a bug(kglobalaccel) has been marked as a duplicate of this bug(frameworks-kxmlgui): https://bugs.kde.org/show_bug.cgi?id=341959#c6

Because no matter which side is to blame, it's the same bug.

@Martin
I just tried and KDE SC4 saves (as also suggested by comment #4) 'Meta+"' for 'Meta+Shift+2', so I'd rather say the bug is in kglobalaccel as the storage side didn't alter?

Not impossible that something in the xcb porting broke (either in kglobalaccel or maybe Qt). I guess the best thing one could do is implementing a unit test for it. Will try to schedule some time for it next week.

unit test created: https://git.reviewboard.kde.org/r/122979/

Now all we need is a test case for the problematic condition and then a fix ;-)

*** Bug 345495 has been marked as a duplicate of this bug. ***

I already proposed a fix in the other bug report. Can you take a look at that?

I don't understand that change

(In reply to Martin Gräßlin from comment #19)
> I don't understand that change

The relevant bit is using "1" as col parameter, which selects the first level shifted symbol.
I assume a "correct" fix would first obtain the modifiers (✔)  and then uses that value to select the "proper" shift degree (where "proper" depends on what the config lib writes ....)

I'll now copy the brainfucking(!) comment from xcb:
--------------------------------------------------------------------------------------

Use of the 'col' parameter:

A list of KeySyms is associated with each KeyCode. The list is intended
to convey the set of symbols on the corresponding key. If the list
(ignoring trailing NoSymbol entries) is a single KeySym ``K'', then the
list is treated as if it were the list ``K NoSymbol K NoSymbol''. If the
list (ignoring trailing NoSymbol entries) is a pair of KeySyms ``K1
K2'', then the list is treated as if it were the list ``K1 K2 K1 K2''.
If the list (ignoring trailing NoSymbol entries) is a triple of KeySyms
``K1 K2 K3'', then the list is treated as if it were the list ``K1 K2 K3
NoSymbol''. When an explicit ``void'' element is desired in the list,
the value VoidSymbol can be used.

The first four elements of the list are split into two groups of
KeySyms. Group 1 contains the first and second KeySyms; Group 2 contains
the third and fourth KeySyms. Within each group, if the second element
of the group is NoSymbol , then the group should be treated as if the
second element were the same as the first element, except when the first
element is an alphabetic KeySym ``K'' for which both lowercase and
uppercase forms are defined. In that case, the group should be treated
as if the first element were the lowercase form of ``K'' and the second
element were the uppercase form of ``K.''

The standard rules for obtaining a KeySym from a KeyPress event make use
of only the Group 1 and Group 2 KeySyms; no interpretation of other
KeySyms in the list is given. Which group to use is determined by the
modifier state. Switching between groups is controlled by the KeySym
named MODE SWITCH, by attaching that KeySym to some KeyCode and
attaching that KeyCode to any one of the modifiers Mod1 through Mod5.
This modifier is called the group modifier. For any KeyCode, Group 1 is
used when the group modifier is off, and Group 2 is used when the group
modifier is on.

The Lock modifier is interpreted as CapsLock when the KeySym named
XK_Caps_Lock is attached to some KeyCode and that KeyCode is attached to
the Lock modifier. The Lock modifier is interpreted as ShiftLock when
the KeySym named XK_Shift_Lock is attached to some KeyCode and that
KeyCode is attached to the Lock modifier. If the Lock modifier could be
interpreted as both CapsLock and ShiftLock, the CapsLock interpretation
is used.

The operation of keypad keys is controlled by the KeySym named
XK_Num_Lock, by attaching that KeySym to some KeyCode and attaching that
KeyCode to any one of the modifiers Mod1 through Mod5 . This modifier is
called the numlock modifier. The standard KeySyms with the prefix
``XK_KP_'' in their name are called keypad KeySyms; these are KeySyms
with numeric value in the hexadecimal range 0xFF80 to 0xFFBD inclusive.
In addition, vendor-specific KeySyms in the hexadecimal range 0x11000000
to 0x1100FFFF are also keypad KeySyms.

Within a group, the choice of KeySym is determined by applying the first
rule that is satisfied from the following list:

* The numlock modifier is on and the second KeySym is a keypad KeySym. In
  this case, if the Shift modifier is on, or if the Lock modifier is on
  and is interpreted as ShiftLock, then the first KeySym is used,
  otherwise the second KeySym is used.

* The Shift and Lock modifiers are both off. In this case, the first
  KeySym is used.

* The Shift modifier is off, and the Lock modifier is on and is
  interpreted as CapsLock. In this case, the first KeySym is used, but
  if that KeySym is lowercase alphabetic, then the corresponding
  uppercase KeySym is used instead.

* The Shift modifier is on, and the Lock modifier is on and is
  interpreted as CapsLock. In this case, the second KeySym is used, but
  if that KeySym is lowercase alphabetic, then the corresponding
  uppercase KeySym is used instead.

* The Shift modifier is on, or the Lock modifier is on and is
  interpreted as ShiftLock, or both. In this case, the second KeySym is
  used.

-------------------------

you had been warned ...

The cause is just an inconsistency. When setting up the shortcut, the shortcut is recorded as, say, Ctrl-@. When I pressed the key combination, kglobalaccel will get the keys using xcb, which would result in Ctrl-Shift-2. And the shift is then removed because isShiftAsModifierAllowed returns false.

My patch check for the removed Shift, and change the key symbol to the shifted key symbol. Alternative solution would be make isShiftAsModifierAllowed return true, and record the shortcut as Ctrl-Shift-2. I don't know where is the code responsible for recording shortcuts, though.

Also, kglobalaccel correctly handle the shortcut (although it triggers the wrong action) because in grabKey(), the Shift is added back for this particular case...

(In reply to yshuiv7 from comment #21)
> Alternative solution would be make isShiftAsModifierAllowed return true, and record the 
> shortcut as Ctrl-Shift-2.

The by far more sane solution, but on costs of KDE4/backward compatibility:
all your configured shortcuts are nuked and default shortcuts in an incompatible SC4 version will fail
:-(

As of the patch, if you want to give it a try, I'd suggest to check whether "keyModX & KKeyServer::modXShift()" and in case directly "keySymX = xcb_key_press_lookup_keysym(m_keySymbols, pEvent, 1);"
This will only cover the switch condition, but I don't know the exact storing mechanics either at hand.

Ideally provide patches through git.reviewboard.kde.org =)

I have this same problem. I map alt-1, alt-2 etc. as "Switch to Desktop #" and shift-alt-1, shift-alt-2 etc. as "Window to Desktop #". The shift+alt combinations no longer work in 5.2.2.

This same exact bug hit when going from KDE 3 to KDE 4 and it took over a year to be fixed. Now it's back; I hope it doesn't hang around for as long.

I have the same problem. Switching keyboard layout with Ctrl+Shift+1/2/3 no longer works. 

Not that it matters, but this key combination can be used in MSWindows to switch keyboard layout, so it shouldn't be that uncommon.

In Debian Unstable KDE was recently updated to 5.3.2. And since then I can't use meta+shift + somekey or Alt or Ctrl + Shift + Somekey. The shift just gets ignored.

I opened a bug report for debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794501

And maybe somebody could change the status to confirmed. There have been enough reports here to confirm this bug.

Moving to kglobalaccel since we've a pending patch on that side (linked)

*** Bug 351825 has been marked as a duplicate of this bug. ***

Those affected by this problem: please try the patch on https://git.reviewboard.kde.org/r/124893

(In reply to Martin Gräßlin from comment #29)
> Those affected by this problem: please try the patch on
> https://git.reviewboard.kde.org/r/124893

Hello Martin,

I tried this patch on kglobalaccel version 5.13.0 from Debian Sid. I patched their sources and build myself a package out of it. But sadly the patch doesn't change anything. I'm still not able to use Meta+Shift+Tab to switch the virtual desktops in reverse.

This patch is *not* supposed to fix any present issues with backtabbing.
The special handling exists because the originally presented patch broke backtabbing (while it did work before, ie should work right now - backtabbing has specialised code everywhere anyway, that's why the patch explicitly excludes it)

It does notably *not* address bug #351255 (failure of mapped modkey detection)

=> If you have issues with (especially) backtabbing even before, you're not getting it fixed by that patch.

What *should* work with the patch (but not without) is eg. Ctrl+Shift+2 - and even then it might still be required to restart kglobalaccel at runtime (if you're not on a US layout)

   pkill kglobalaccel5
   kglobalaccel5

(In reply to Martin Gräßlin from comment #29)
> Those affected by this problem: please try the patch on
> https://git.reviewboard.kde.org/r/124893

Confirmed that works! Thank you!

Git commit 7bc0f483e3e393ffecccc4eb86df2a2b1cd9d581 by Thomas Lübking.
Committed on 05/10/2015 at 21:19.
Pushed by luebking into branch 'master'.

fix handling of irregular 1st level shifts

if a key has a different symbol on the first level
shift (ie. not upcase, affects non-alphabetic keys)
it's not sufficient to just strip the SHIFT modifier
but the actual symbol for the 1st level shift needs
to be fetched.

Thanks to Yuxuan Shui for initially working on this.
REVIEW: 124893

M  +6    -1    src/runtime/plugins/xcb/kglobalaccel_x11.cpp

http://commits.kde.org/kglobalaccel/7bc0f483e3e393ffecccc4eb86df2a2b1cd9d581

I installed kglobalaccel5-5.15.0git.20151005T231957~bf71e53-2.1.x86_64 from my distro's packages (Opensuse).

The Opensuse devs say it's supposed to already have the fix provided here.

It doesn't work on my machine so they told me to add a comment here.

At KDE's "System Settings" > "Shortcuts" > "Custom Shortcuts" > "Configure Input Actions settings" I created a new action ...

 Name = test
 Trigger = Meta+Ctrl+Alt+T
 Action = t:e:s:t:Shift+2
 Window = [X] Active window

... then Click'd "Apply".

But if I type "Meta+Ctrl+Alt+T" in any window , absolutely nothing happens.  There's no output at all.

this has nothing to do with this bug.
this bug was about shortcut matching if the shortcut included a "shift" (so you press eg. ctrl+shift+2 but the expected shortcut was ctrl+")

you seem to have a problem with khotkeys? (do you think it's related to the shift in the to-be-generated keypresses?)

Hi,

> you seem to have a problem with khotkeys? (do you think it's related to the shift in the to-be-generated keypresses?)

I honestly don't know :-(  I'm really confused about what broke between 'old' KDE4 and the new plasma5 versions.  It used to work.

I've been trying to follow the problem through posts and bugs and khotkeys and kglobalaccel both seem to be mentioned alot but i don't know how to figure out which one for sure.

I can try to specific info you request if that'll help get this into the right place.

My goal is just to get shortcuts to work again.

Could somebody please point to the right place to file 'my' bug?

It's not "here" apparently.

And looking in Bugzilla

http://is.gd/TLsAlk

there's lots of these "shortcuts don't work" bugs that are going nowhere.  I don't want to create more noise, I want to help get it fixed.  If only by putting my report in the right place.

Well, the most important question is what doesn't work for you
a) the global shortcut "Meta+Ctrl+Alt+T" in general (ie. you cannot bind it to eg. show krunner or similar)
b) the execution of "t:e:s:t:Shift+2" (or any other synthetic key presses)

> what doesn't work for you

It looks like 2 things aren't working.  Here's some output tests.

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)

can you bind "Meta+Ctrl+Alt+T" to any of the actions in "kcmshell5 keys"?

I'm not 100% sure what you mean by "kcmshell5 keys".

Digging around a bit, are you talking about the "Global Keyboard Shortcuts" for different 'KDE components'?

If I choose

KDE component = krunner

and change

"Run command"

from

Global = Default: Alt+Space (which works)

to

Global = Custom: Meta+Ctrl+Alt+T

yes, it works using "Meta+Ctrl+Alt+T"

Ok, that means the problem is contained in khotkeys (global accels in general work)

https://bugs.kde.org/buglist.cgi?product=khotkeys&component=general&resolution=---&list_id=1301814

Judging from that list, the component is
a) severely broken
b) virtually unmaintained :-(

There're actually some bugs that sounds like yours.

Okay, khotkeys it is!

Wow that's a long list going back for many years :-(

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" that should be fixed?

Something or someone broke it apparently.  Are 'they' the ones who are supposed to fix it?  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.

I tacked on my comments & tests to

"Bug 337230 - frameworks port not working at all"
https://bugs.kde.org/show_bug.cgi?id=337230#c13

Seemed best fit :-/  But, it's also marked "fixed" so I dunno.

I see lots of those bugs listed as "unconfirmed".  How many user reports does it take on an issue before a bug is "confirmed"?  Do we need to be doing something else?

*** Bug 211278 has been marked as a duplicate of this bug. ***

After reading into several of those bugs, they're actually different (shift related bugs that point this one, a ctrl "replay" that wanted to trigger ctrl and failing assignments in general)

Just file a new bug.

The worst khotkeys bug is actually bug #343891 since it means one cannot on anything one attempts to configure (assigning ctrl could have indeed failed randomly ...)

kglobalaccel is a global shortcut handler - it holds passive grabs on the keyboard and when it sees a known combination, informs the interested application.

One of those applications is khotkeys, which does random configurable things in return (where "normal" applications would have a set of predefined actions, like kwin to switch the virtual desktop etc.)

opened a NEW bug: https://bugs.kde.org/show_bug.cgi?id=353781

*** Bug 347852 has been marked as a duplicate of this bug. ***

I just tested kglobalaccel 5.16 in arch linux and while 'ctrl + !' now works as a shortcut, neither 'ctrl + "' nor 'ctrl + §' work, so this seems to only be a partial fix.

run
   pkill kglobalaccel5; sleep 5; kglobalaccel5 &

"fixed"?

That did the trick. Thanks.

I took the wild guess that !"§ refers to qwertz and that your session starts on a qwerty layout and is altered during the session (and the qt event processor hides the relevant event from us ...)

See https://bugs.kde.org/show_bug.cgi?id=350816

Unless you're willing to restart kglobalaccel all the time, add something like (you want to adjust matches and options):

/etc/X11/xorg.conf.d/11-keyboard.conf
--- snip ----------------

Section "InputClass"
    Identifier          "Keyboard Defaults"
    MatchIsKeyboard     "yes"
        MatchProduct "Microsoft Comfort Curve Keyboard 2000"
    Option              "XkbLayout" "de"
    Option              "XkbVariant" "deadgraveacute"
    Option              "XkbModel" "microsofccurve2k"
    Option              "XkbOptions" "terminate:ctrl_alt_bksp,compose:caps"
    Option              "XkbRules" "xorg"
    Option              "XkbKeycodes" "evdev"
EndSection

I'm on 5.17.0 on Gentoo amd64 and killing kglobalaccel5 does not "fix" the issue. If I put XbkLayout (I use an IT layout) in xorg.conf, then global shortcuts work but for example Ctrl+Z does not work anymore in editors (sublime, kate). Also in nano on Konsole I have to use ctrl+shit+x in order be able to exit.

On the other way if I don't put XbkLayout on xorg.conf, then global shortcuts does not work unless I kill and relaunch kglobalaccel5. If I do this, then I have the Ctrl+Z issue described above.

(In reply to Francesco from comment #53)

> If I put XbkLayout (I use an IT layout) in xorg.conf, then global
> shortcuts work
[...]
> On the other way if I don't put XbkLayout on xorg.conf, then global
> shortcuts does not work unless I kill and relaunch kglobalaccel5. If I do
> this, then I have the Ctrl+Z issue described above.

Err, restarting kglobalaccel5 resp. setting the layout in xorg.conf *does* work on global shortcuts - so this is really just bug #350816

=> reply on that bug, sounds terribly unrelated to this one here (you mentioned no problem with shift keys at all)


The problem that then arises is that ctrl+z (anything else?) won't work in local contexts - from your description it sounds as if the shortcut is assigned globally (or at least grabbed away)

italy + ctrl+z sounds like some qwerty ./. qzerty conflict?
=> so which layout is it supposed to be and what's the output of "setxkbmap -print" and "setxkbmap -query"?
Also attach your ~/.config/kglobalshortcutsrc over there.

> Also in nano on Konsole I have to use ctrl+shit+x in order be able to exit.
Assuming I've never used nano - what's the supposed shortcut?

Where was this 'fixed'?

Still a problem here, and elsewhere (https://marc.info/?l=kde&m=145469233519878&w=2)

No, it's not.

See comment #33 on the fixing commit; it's in kglobalaccel 5.16.

The linked mailing list post apparently describes bug #353781 which is a Qt5 bug.
The invocation of a global shortcut has nothing to do with the active window (except for window rules to suppress them, but that's not it either)

Ok, so it's not this either.

Fact is, 'KDE Shortcuts' don't work.  Add they haven't consistently since KDE4.  Full stop.

That there's a 1000 reasons, and a 1000 bugs filed, helps noone.  Neither does kicking it upstream to Qt5 where it gets ignored some more.  All it does it hurts KDE and its users.

This will never get fixed/addressed unless/until some capable dev 'owns' KDE Shortcuts again.

"Fact is" that you made a pretty bold statement without the least knowledge, understanding or ability to read context and are now approaching a pretty poor aggressive attempt to bail out, yet just re-expose your defects: That bug is, as written, a bug in Qt5 - it has nothing to do with KDE nor even with shortcuts; Qt5 deals synthetic events wrongly by accounting the HW modifier state instead of the logic one. That those synthetic events are triggered by a shortcut in the particular case is completely irrelevant.

I suggest to shut up now until you can make informed comments instead of continuing that self embarrassment.

You're funny!

Good luck with your broken POS.

p.s.

Try ESL ...

qed.

Does it really matter whose bug it is? If Qt5 isn't a usable platform for doing such simple things, then KDE 5 either shouldn't have used Qt5, or shouldn't have been released as stable until the thing actually worked. Shortcuts were broken for over a year after the "stable" release of KDE 4, and now they've been broken for a year and a half since the "stable" release of KDE 5. And it's not an isolated thing — every time a component is rewritten to use the framework de jour, it comes back less functional and with more bugs. And then it's released anyway despite all of the regressions. It's a miserably dysfunctional system.

(In reply to Andrew Rodland from comment #61)
> Does it really matter whose bug it is?
Yes.
I'll try that *once* again. If I have to again, I'll start getting mean - so you better read closely:

That bug over there is NOT a bug in khotkeys (let alone kglobalaccel) - you cannot even reliably "xvkbd -sendevent" or "xdotool key" to *ANY* Qt5 client, but that doesn't mean it's a xvkbd or xdotool bug, is it?


> "stable" release of KDE 5
KDE5 is anything but stable as of today. KScreen is still a disaster, konsole virtually unmaintained - and there are really severe (not like this, I mean *severe*, QScreen can crash any application on randr events, QtQuick is a resource hog and crashes whenever it feels like) bugs in Qt5 which *might* *partially* be resolved with Qt5.6 - who the fuck spreads such bullshit information? And even if, one must be really DUMB to believe them despite what one sees. DUMB AS FUCK.

> That bug over there is NOT a bug in khotkeys (let alone kglobalaccel) - you cannot even reliably "xvkbd -sendevent" or "xdotool key" to *ANY* Qt5 client, but that doesn't mean it's a xvkbd or xdotool bug, is it?

I agree entirely. I just don't see any reason why a user should care which specific piece of software is broken. "I can't set and use shortcuts with shift + other modifiers" is a real, and open, user defect, which has not been fixed by anyone at all. I don't care whether or not it's khotkeys' fault, whether or not it's kglobalaccel's fault, or whether or not it's Qt's fault, and neither does anyone else.

> KDE5 is anything but stable as of today. [...] who the fuck spreads such bullshit information?

Whoever engineers all of those releases and release announcements and decides that they're worthy of a name other than "beta", I suppose. In other words, KDE.

> And even if, one must be really DUMB to believe them despite what one sees. DUMB AS FUCK.

Well, you know, the world is full of stupid people. But given that KDE 4 is officially unmaintained since 2015, a packager's choice pretty much boils down to packaging KDE 5 in stable distributions, or saying "oh well, I guess there's no stable release of KDE anymore" and going home.

No, *this* bug here (341959) is resp. *was* a bug in kglobalaccel and it *is* fixed in 5.16 (i think, please don't nail me on that - check the commit if you care) and onwards.

The bug described in comment #55 is however entirely different and unrelated (why I got slightly annoyed when it was brought up to claim *this* bug would not be fixed)

If you've remaining issues assigning (global!) shortcuts, see

(AltGr related)
https://git.reviewboard.kde.org/r/126571/
https://git.reviewboard.kde.org/r/126600/

(non US layout related)
https://git.reviewboard.kde.org/r/125786/

What a user sees is matter to quality assurance, it's totally irrelvant in bugtracking, otherwise we could just open one giant "KDE sucks" bug - won't get anything done.

What we do here right now is technically spam - off topic discussion that stashes the relevant information.