The TabBox implements methods for those events and performs same
logic as on X11. Click outside of TabBox closes. If the event is on
the TabBox we don't filter the event out and let the internal filter
forward the event.
A QEvent* is passed around, this could also be a QWheelEvent. Only
present windows static casted, all other effects verified.
Documentation is not existing, so we don't know what was intended.
By using QWindow we can also find the TabBox window on Wayland where
the winId is not really helpful.
This also changes the elevation from Unamanged to Toplevel, so that
it is no longer X11 specific.
Result: TabBox stays on top of all windows also on Wayland.
This method is able to match a QWindow created by KWin to a Toplevel.
On X11 by matching winId against Unmanaged, on Wayland by matching
to internal window of ShellClient.
Finding the internal window is a commonly needed feature to e.g.
elevate the TabBox window.
A transient window should always be visible on the current screen.
This change ensures that a transient is always placed in a way that
the transient window is visible on the screen ignoring the transient
offset hint if it has to be.
Unfortunately QtWayland doesn't set the transient hint correctly:
a sub menu is a transient to the main window and not to the parent
menu resulting in quite off positioned menus, see:
https://bugreports.qt.io/browse/QTBUG-51640
Need to add client pos to the transient's position. The offset is
relative to the parent surface, but the client doesn't know about the
size of the decoration, thus KWin needs to add it.
Test creates windows and transients for it and verifies the position.
For decorated windows the position is currently broken as it does not
consider the adjusted client position.
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.
