As soon as you're in the TabBox it works normally again. On Wayland it works in general. When setting a custom Key in System settings other than Alt+Shift+Tab, it also works on X (but then in TabBox you've to use the default key again ... probably not related though). Happens on: KDE Neon user edition and dev unstable. Reproducible: Always Steps to Reproduce: 1. Press Alt+Shift+Tab Actual Results: Switch to next window in list Expected Results: Switch to last window in list
This seems to be related to the matching with backtab. The shortcut is registered in kwin as "Alt+Shift+Backtab" - this doesn't make sense. Backtab consumes the shift key, so it should be "Alt+Backtab". Or without consuming "Alt+Shift+Backtab". That it works correctly on Wayland is actually a bug as it doesn't handle consumed modifiers yet. So it can match Alt+Shift+Backtab. Just right now I'm working on a change to handle consumed modifiers correctly on Wayland and with that it also doesn't trigger any more. The shortcut to match is then Alt+Backtab, but there is nothing which matches that.
That total mess is now documented in https://phabricator.kde.org/D2768
Git commit 4235871667f402a6fdd52f91865f74c618d5c400 by Martin Gräßlin. Committed on 14/09/2016 at 08:25. Pushed by graesslin into branch 'master'. Remove not-wanted modifiers prior to evaluating global shortcuts Summary: When triggering global shortcuts we are more interested in the hold keys than the currently active modifiers. E.g. capslock should not be seen as "shift is hold". Similar we need to remove consumed modifiers. Shift+5 is % and not Shift+% - the shift modifier is consumed and needs to be removed from shortcut evaluation. To support this we need to have the actual state directly from xkbcommon. Thus a new method is added which exposes the modifiers relevant for global shortcut matching. In addition on every key press all consumed modifiers are calculated and kept so that they can be used for shortcut matching. In addition a workaround is added for Backtab. Similar workaround exists in kglobalaccel for X11. The problem is that our shortcuts are stored incorrectly: Shift+Tab instead of Backtab. Thus a mapping back is required. To make everything worse KWin registers the wrong key sequence "Alt+Shift+Backtab" which doesn't make any sense and is broken on X11 at least. The workaround supports both special cases. The one for Backtab should be turned into Shift+Tab and also KWin's special case of adding shift to backtab. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2768 M +0 -1 autotests/integration/globalshortcuts_test.cpp M +0 -1 autotests/integration/tabbox_test.cpp M +24 -7 globalshortcuts.cpp M +1 -1 input.cpp M +38 -0 keyboard_input.cpp M +3 -0 keyboard_input.h http://commits.kde.org/kwin/4235871667f402a6fdd52f91865f74c618d5c400
Further testing shows that QKeySequenceEdit captures Shift+Backtab, so just changing KWin to use Backtab to Tab won't fix the general problem. Looks like we need workarounds on X11 like on Wayland.
Reassigning to kglobalaccel as the workaround needs to be added there.
Git commit 4fe25b7190656ea44cd073ad9f61450a3de8e8f0 by Roman Gilg. Committed on 15/01/2017 at 14:23. Pushed by romangilg into branch 'master'. Allow Tab as being modified by Shift Backtab was already in the list of allowed keys, but not Tab, which happens to get queried though. In the case of bug 368581 when walking in reverse direction of windows by pressing Alt+Shift+Tab. Reviewers: graesslin Differential Revision: https://phabricator.kde.org/D4141 M +1 -0 src/kkeyserver.cpp https://commits.kde.org/kwindowsystem/4fe25b7190656ea44cd073ad9f61450a3de8e8f0