Summary:
With this change the ModifierOnlyShortcut starts to track the actual
pressed keys instead using a counter of combined pressed keys.
This should help for the cases that we get unsynced key codes.
E.g. if we get two key presses for the same key and only one release
we don't get out of sync. Similar if we get a key release for a key
which wasn't pressed, we don't go out of sync.
Test Plan: Auto test still passes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4617
Summary:
The functionality regarding triggering modifier only shortcuts is moved
out of Xkb - where it doesn't belong to - and is turned into an input
event spy listening for the changes it is interested in. Previously
the state got queried by asking e.g. for the pressed buttons, now it's
tracked directly.
The X11 side needs a larger change due to that as now pushing the events
into Xkb does not trigger modifier only shortcuts any more. Instead the
"normal" way through the platform API needs to be used which triggers the
processing of filters and spies.
The problem here is that our redirections only process events if they are
inited and that only happens on Wayland. We cannot call init on them as
that would create all the Wayland filters and spies and processing would
probably break. As an intermediate solution the spies are now processed
and there we know that it won't matter. A future solution would be to
remove the init checks completely and just send through both filters and
spies and ensure that on X11 only the supported ones are loaded.
Closes T5220
Test Plan: Tested on Wayland and X11
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Maniphest Tasks: T5220
Differential Revision: https://phabricator.kde.org/D4578
Summary:
So far the keyboard repeat handling was triggered directly from
KeyboardInputRedirection::processKey. With the introduction of
InputEventSpies it is no longer required to be done like that, we can
split it out into a dedicated spy.
This means that processKey only has to care about processing the key
and allows us to better extend in future. So far keyboard repeat is
only functional for libinput based platforms. But it should also be
possible to use it in nested setups. By splitting it out we can
prepare for that.
Test Plan: Auto-test using repeat still passes
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D4304
its own directory, cleaned up the effect config macros and renamed
"MakeTransparent" to "Translucency" so that it matches its visible name.
svn path=/trunk/KDE/kdebase/workspace/; revision=921749
being v2+ (right now it says just GPL, which according to GPL itself
means any GPL). Decoration clients will come later.
CCMAIL: kwin@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=742302
You can configure shadow's offset and opacity and presentwindow's mouse activation areas
(e.g. activate when mouse it at top-right corner).
svn path=/trunk/KDE/kdebase/workspace/; revision=669040
ATM you can toggle them on/off, but KWin part isn't done yet, so KWin doesn't care about your changes yet.
You can try it with 'kcmshell kwineffects'
svn path=/trunk/KDE/kdebase/workspace/; revision=668251
Martin Gräßlin
Martin Gräßlin
Lucas Murray
Laurent Montel
Luboš Luňák
Rivo Laks
Bernhard Loos
Arto Hytönen
Matthias Kretz