I recently upgraded to 5.38 and it broke the functionality some kwin shortcuts, e.g. "move window to next desktop". Also tried with new user, with clean configs. Downgrading kwindowsystem to 5.37 resolves the issue.
what's the shortcut you try to use?
*** Bug 384601 has been marked as a duplicate of this bug. ***
*** Bug 384602 has been marked as a duplicate of this bug. ***
Looks like Ctrl+Alt+Shift+[key] are broken also, where [key] are not only arrows, but also at least Del and PgUp (e.g. logout/restart without confirmation default shortcuts), maybe any key combination using Shift+[Alt|Meta].
(In reply to Martin Flöser from comment #1)
> what's the shortcut you try to use?
Ctrl+Alt+Shift+Left/Right to move window to previous/next virtual desktop
I'm having same issue after KDE upgrade to 5.38 on Archlinux
I can confirm this one (running Arch Linux as well)
*** Bug 384634 has been marked as a duplicate of this bug. ***
Hi, The same here.
I can confirm in archlinux. The shortcut don't work since I update
extra/kwindowsystem 5.38.0-1 (kf5)
The bug is in kglobalaccel not in kwindowsystem.
I'm having the same issue on Arch. The shortcut I'm using is ctrl + shift + spacebar.
Is anyone able to reproduce this on Wayland, or just X11?
KGlobalAccel has only gotten one consequential many commit since 5.37: https://cgit.kde.org/kglobalaccel.git/commit/?id=2c20ddff034e4958bf0536ca91ae9e444955305d
(In reply to Nate Graham from comment #12)
> Is anyone able to reproduce this on Wayland, or just X11?
Wayland should not be affected. The change you mention only affects X11.
Reverting the commit 2c20ddff034e4958bf0536ca91ae9e444955305d indeed fixes the bug.
Seems graesslin was right about not trusting this change. Oh, the joys of being a maintainer...
upgraded kglobalaccel (5.38.0-1 -> 5.38.1-1)
*** Bug 384709 has been marked as a duplicate of this bug. ***
Also upgraded kglobalaccel (5.38.0-1 -> 5.38.1-1) and this fixed my issue as well!
I don't see any new commits to the kglobalaccel repo. Are distros patching this out?
Either way, we should revert the commit until we can find out what went wrong.
Can confirm it is fixed, but why?
Arch has not made a change to the package: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kglobalaccel&id=82c50bed02e8de51c11588a2d4e2cc84e59bf7f0
@grmat(In reply to grmat from comment #19)
> Can confirm it is fixed, but why?
> Arch has not made a change to the package:
They updated the version. kglobalaccel 5.38.1 has the change mentioned in #12 reverted if I understand #14 correctly.
You're right. I haven't seen it (like Nate Graham) because it's not in the master branch.
Great, marking this as fixed, then.
It's not fixed. A tarball has been released with the commit reverted, but trunk is still broken and a proper fix needs to be committed.
*** Bug 384731 has been marked as a duplicate of this bug. ***
It is now impossible to bind the Meta key to the panel's application launcher.
The Meta key does not work, and additionally it resets itself to Alt+F1 after reboot.
(Version 5.38.1-1 on Arch Linux)
I'm not sure if this is related, but I cannot use the shift key to move backwards through applications now when using Alt-tab switching. Should I file this as a new bug?
Git commit 68e35f234ca7d866bcb54442d22892450d871848 by Martin Flöser.
Committed on 25/09/2017 at 15:30.
Pushed by graesslin into branch 'master'.
Revert "KGlobalAccel: port to KKeyServer's new method symXModXToKeyQt, to fix numpad keys"
This reverts commit 2c20ddff034e4958bf0536ca91ae9e444955305d.
I'm reverting as we don't have a fix yet and the next release is too
close to risk any changes. As explained in the original review request
for this feature: touching this code base is dangerous. The code is
A month of living in master was not enough to spot the severe regressions
we had. As we are now only a few days away from next release we cannot
expect to discover regressions any fix would cause. I don't really see a
solution to this problem: any change might cause issues especially in
KWin, KScreenLocker and KGlobalAccel. All of them have the problem that
the maintainer of those components is not running X11 and won't spot the
regressions. Futhermore we don't have any test cases for the complete key
handing stack on X11. We won't find the regressions. My personal
recommendation would be to no longer change the X11 side and instead all
together work on Wayland and get it ready. There the world looks better:
we have a sane input stack which is completly unit tested. The first
regression caused by the changes here was discovered by a KWin test case
for Wayland. That's the world where we can change and improve the stack.
Let X die, long live Wayland!
If someone wants to take on the task to improve the X11 stack here I
expect some serious work on the testability of this fragile stack. If we
see that the shortcuts will still match I would be way more confident to
accept a change.
M +45 -7 src/runtime/plugins/xcb/kglobalaccel_x11.cpp
*** Bug 385073 has been marked as a duplicate of this bug. ***