Currently, the trend is to get the coordinates of the hotspot and map it
to the device independent pixels at the call site.
This change makes the KXcursorSprite return the coordinates of the hotspot
in the device independent pixels to reduce the amount of duplicated code.
Otherwise we'll show a dangling cursor but otherwise the cursor will be
updated by other code paths, so we end up with a weird cursor in the
middle of the screen that doesn't move.
Kwin's VirtualDesktop saved a different configuration per X screen. This
messes up with a recent refactor of our startup as now we load
virtualdesktops before the X11 screen number is set and we load from the
group "Desktops-screen--1" then save to another place.
For a wayland session it doesn't make sense to have such a strong X
tie-in. We may as well just tidy this up.
Multihead has been deprecated for a decade. There is absolutely no way
Plasma supports it. Worst case if someone magically is using mutlihead
they just get syncronised virtual desktops.
BUG: 424571
In rare cases, Workspace::restoreFocus() may fail, for example when the
most recently activated client is about to be destroyed or unmapped.
If it happens that we cannot restore the focus, then mark the window in
FocusIn event as active.
CCBUG: 424223
Fix regression that was introduced by a mismatch in the default value of
ActiveMouseScreen option between kwin.kcfg and kwinoptions_settings.kcfg
BUG: 424389
(cherry picked from commit c853f8313a213a0f7d0f98f662f7e98849d547ca)
If AbstractClient::setFrameGeometry() is called from a slot connected
directly to the frameGeometryChanged() signal, then is there a good
chance that kwin will fall into an infinite recursion. However, that's
the case with only X11 and internal clients.
The root cause of the infinite recursion is that both X11Client and
InternalClient compare the new geometry against the geometry before
update blocking. In order to fix the bug, we simply need to ensure that
updateGeometryBeforeUpdateBlocking() has been called before we start
emitting the frameGeometryChanged() signal.
Furthermore, a couple of tests were added to ensure that we won't hit
this subtle bug again.
Unfortunately, a0c4a8e766 has a major bug
where clients that track focus events may get confused by focusToNull().
One such a notable example is Dota 2. It tracks the focus events to
minimize itself after the keyboard focus has been lost as well stop
playing music while it's in background. So, when we call focusToNull(),
Dota 2 will receive a corresponding FocusOut event and ask the window
manager to minimize it. It doesn't really matter that the FocusOut
event is going to be followed by a FocusIn event because when a window
is minimized, kwin will activate the next one in the focus chain.
Since those issues can't be fixed from the window manager's side, this
patch partially reverts a0c4a leaving only the autotest.
BUG: 424223
FIXED-IN: 5.19.4
