Summary: | With no opened TabBox it switches with Alt+Shift+Tab to next window instead of previous one (on X) | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kglobalaccel | Reporter: | Roman Gilg <subdiff> |
Component: | general | Assignee: | Martin Flöser <mgraesslin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kdelibs-bugs |
Priority: | NOR | ||
Version: | 5.24.0 | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/kwindowsystem/4fe25b7190656ea44cd073ad9f61450a3de8e8f0 | Version Fixed In: | |
Sentry Crash Report: |
Description
Roman Gilg
2016-09-11 08:51:11 UTC
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 |