Drag'n'Drop on Wayland allows us to improve the drag'n'drop experience.
When entering a window during the drag'n'drop operation, KWin raises it.
BUG: 36065
FIXED-IN: 5.6.0 (Wayland only)
QDialog or at least QMessageBox does this and I doubt Lubos' idea was to
"allow focus stealing if the client nags enough" - switching the VD is a
major interrupt and prevented when a new window shows up.
It should not be possible to stomp on ground and then receive
focus - notably not on the other desktop.
I assume the original idea was to let clients distribute focus *inside*
across virtual desktops, maybe also permit when no client was active,
but hardly otherwise.
BUG: 359683
FIXED-IN: 5.6
REVIEW: 127153
Try to fix test on CI system. With neither a config nor the env variables
the cursor selection falls back to the default cursor theme, which might
not contain the cursors we need.
even if scaled or translated, if WindowForceBlurRole is set
do the blur anyways
same thing for backgroundcontrast
reviewed by: Martin Gräßlin <mgraesslin@kde.org>
When starting effect mouse interception the current focused window
and or decoration should get a leave event. Similar when the effect mouse
interception ends the current pointer position needs to be evaluated and
a pointer enter be sent if needed.
The test case verifies that setting an override cursor during mouse
interception works and that it's also possible to change it. When
ending mouse interception the cursor image should be adjusted again.
The test shows that when mouse interception starts KWin should send
a pointer leave event to the current focused window and similar needs
to handle the stop of mouse interception.
Updating the focused pointer surface results in the cursor to change.
The CursorImage needs the current focused window to evaluate which cursor
to use, though. Thus we need to make sure that the window reflects the
current state before updating the seat.
This test case verifies that the cursor image and hot spot changes
correctly when focusing a window, changes when damaged and hides.
Test shows that when focusing a window the cursor image is not
removed, neither that unfocus sets back to fallback cursor properly.
The WaylandCursorTheme emits a signal whenever it reloads the theme.
This is used by CursorImage to clear the cache and reload decoration
and fallback cursor.
So far updating the cursor image was not really defined. It was possible
to use the cursor image from the wayland seat or have a custom set cursor
image. But there are no rules in place to decide which one to use when.
With this change a dedicated CursorImage class is introduced which tracks
the cursor image changes on the seat, on the decoration, in the effects
and so on. In addition it tracks which is the current source for the
image, that is whether e.g. the cursor from the seat or from effects
override should be used. Whenever the cursor image changes a signal is
emitted, which is connected to the signal in AbstractBackend.
Based on that the backends can directly show the image. The existing
code in the backends to install a cursor shape or to install the cursor
from the server is completely dropped. For the backend it's irrelevant
from where the image comes from.
A new feature added is that the cursor image is marked as rendered. This
is then passed on to the frame rendered in the Surface and thus animated
cursors are finally working. Unfortunately animated cursors are broken in
Qt (see https://bugreports.qt.io/browse/QTBUG-48181 ).
When the client's palette changes we need to update the internal colors
and emit a colorChanged, so that the decoration can repaint.
BUG: 357311
FIXED-IN: 5.5.5
REVIEW: 126891
The theme doesn't load if we pass an incorrect size. This change
implements a resolution dependency size resolution inspired by the
one in Cursor::loadThemeSettings. Ideally this would be a size
different for each screen. As we don't have support for this yet, we
go for first screen.
Small regression: the command didn't get updated at all, so it was always
MouseNothing.
To prevent such a regression to sneak in again the change comes with
autotest for the action on inactive and active window.
KWin starts to track which is the current layout and in case it changes
notifies the org.kde.osdService about the change through DBus. KWin has
a better knowledge about changes than the KeyboardDaemon could have, so
it's better to do in KWin. E.g. KWin can also notice changes not
triggered by the global shortcut, but by the keymap itself.
KWin registers/steals the shortcut of the "KDE Keyboard Layout Switcher"
and binds it to a new method which actually switches the layout.
The actual switcher from which the shortcut is stolen should only be a
representation on Wayland. Though how to do this is a problem for the
future. Only the active window is notified about layout changes and the
plasmoid will never get the event in time. This is of course a minor
problem compared to the fact that the KeyboardDaemon is absolutely X11
dependent.
This is the start for adding proper support for keyboard layouts. If
we have a configuration in kxkbrc the keymap is generated from that
information. This allows to have different layouts and also layout
switching is working (though not yet passed to Wayland clients properly).
Not yet working is the global shortcut for layout switching and
reconfiguring the layouts.
As a Wayland server KWin does not have to emit additional key repeat
events (unlike X11). The clients are responsible for handling this based
on the provided key repeat information.
Internally KWin needs key repeat, though. E.g. the effects need key
repeat (filtering in Present Windows), window moving by keyboard needs
repeat, etc. etc.
This change introduces the internal key repeat. For each key press a
QTimer is started which gets canceled again on the key release. If the
timer fires it invoked processKey with a new KeyboardKeyAutoRepeat state.
This is handled just like a KeyPress, but states are not updated and
the QKeyEvent has autorepeat set to true.
The event filters check for the autorepeat state and filter the event
out if they are not interested in it. E.g. the filters passing the event
to the Wayland client need to filter it out.
Currently auto-repeat is bound to using libinput. This needs to be
modified. The only backend sending repeated events is X11, thus for
other backends it should be enabled.
Whether creating a timer on each key event is a good idea is something to
evaluate in future.
Reviewed-By: Bhushan Shah
General handling for mouse driven focus and auto raise should and can
be shared between Client and ShellClient. Thus the code is moved to
AbstractClient and invoked from Client::enterNotifyEvent.
Experimental testing in real world showed it's just a signing issue
in this specific case. The events passed to wayland clients scroll
in correct direction.
With that all the actions are implemented just like on X11.
There are two not yet implemented differences:
* hide splash window when clicking it
* replay event on special window
Implemented in the ForwardEventFilter: before forwarding the event
to the window we check whether a modifier is pressed and perform the
wheel command.
Possible improvements: each axis event triggers the same change, there
is no adjusted scaling.
