Summary:
Moves most of the implementation from Client to AbstractClient, so that
it can be used for both Client and ShellClient. Only the X11 specific
code is kept in Client.
Not yet implemented is updating the window caption.
Unfortunately the testing of this feature showed that setting a window
shortcut is not working on Wayland at all (the Qt widget doesn't properly
catch the shortcut). So this feature is currently only of erm theoretical
use.
Test Plan: Added new test case. No testing in real world as explained.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6818
Summary:
This is a preparation step for no longer creating a socket in the tests
and slightly simplifies the init test code.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3575
Summary:
A shortcut with e.g. shift+w could not be triggered as shift is
considered as consumed. It transforms the keysym to an uppercase variant
thus it is consumed.
This change checks for the condition that shift is pressed and is the
only consumed modifier. If the current keysym is a letter the shift is
removed from the consumed modifier again to still support the shortcut.
BUG: 370341
FIXED-IN: 5.8.2
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3015
Summary:
If a key could be turned into a keysym with a modifier xkbcommon
considers the modifier as consumed even if not pressed.
E.g. Alt+F3 considers alt as consumed as there is a keysym gnerated with
Ctrl+Alt+F3 (vt switching).
This change tries to workaround the problem by ignoring the consumed
modifiers if there are more modifiers consumed than active. It's
possible that this will create regressions for other shortcuts - we need
to test it in the wild. Although this might cause regressions I'm aiming
for Plasma/5.8 branch with the change. It only affects Wayland and fixes
quite important shortcuts from window manager perspective (desktop
switching (ctrl+f1 to ctrl+f4), desktop grid (ctrl+f8), present windows
(ctrl+f9, ctrl+10), cube (ctrl+f11), user actions (alt+f3), close window
(alt+f4)). If it causes regressions they need to be fixed as well in the
Plasma/5.8 branch.
A new API entry point for xkbcommon was proposed, but is not yet merged
and there is no release with it yet. Once that is available the
workaround should get removed and replaced by the new API call.
BUG: 368989
FIXED-IN: 5.8.1
Test Plan: Going to restart session now with the change
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2945
Summary:
So far KWin tried to repeat all pressed keys which should repeat. But
this is not how X11 and e.g. QtWayland handle it. There only one key -
the last one which got pressed - repeats. And this makes sense as the
key is used to generate a keysym and that one KWin caches. Thus the
logic so far resulted in incorrect keysyms to be generated during the
repeat. E.g. pressing a, pressing b, releasing b would repeat b instead
of the hold a as b was the last generated keysym.
This change addresses this problem and let's only one key repeat at a
time. When the currently repeating key gets released the repeat timer is
stopped and other hold keys won't repeat any more. This also matches the
behavior of X11 and QtWayland.
BUG: 369091
FIXED-IN: 5.8.1
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2941
This adds a new test case for global shortcuts which simulates
triggering a shortcut through key repeat. The test verifies a problem
that the the shortcut continues to be triggered after releasing the key
if another key is still pressed (and triggers repeats).
CCBUG: 369091
Summary:
My compiler doesn't seem to like this constructor, it bails out with the
following error:
/home/sebas/kf5/src/kde/workspace/kwin/autotests/integration/globalshortcuts_test.cpp:
In member function ‘void GlobalShortcutsTest::testConsumedShift()’:
/home/sebas/kf5/src/kde/workspace/kwin/autotests/integration/globalshortcuts_test.cpp:79:40:
error: no matching function for call to ‘QAction::QAction()’
QScopedPointer<QAction> action(new QAction);
^~~~~~~
Using this as first argument fixes the build on my machine.
Test Plan: screenedges test fails, others pass. (this screenedges test failure seems unrelated)
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: luebking, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2782
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.
CCBUG: 368581
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2768
New test case to verify that global shortcut triggering works correctly.
First test case is to verify that consumed modifiers do not break the
shortcut. E.g. a shortcut registered for % should trigger on Shift+5 on
us layout. For that the modifier needs to be consumed, otherwise it's
Shift+% and doesn't trigger. As the test shows this is currently the
case.
