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
Implemented for Global, Virtual Desktop and Application layout policies.
Not implemented for Window policy due separate windows do not preserve
their IDs between sessions (still could be implemented the same way as for Application policy).
Layout saving/restoring happens on Session save/load.
Covered by unit tests
Currently, we update the input transformation matrix for the focused
pointer surface only when the frameGeometryChanged() signal is emitted.
However, since the input transformation matrix is computed based on the
current position of the upper left corner of the main surface, it is
wrong to do so because the frame geometry is a logical geometry that
doesn't have any direct relationship with the buffer geometry, i.e. the
rect on the screen occupied by the main surface.
If the input transformation matrix gets out of sync, user may notice
that pointer events are "shifted."
This change introduces a new signal that's emitted when the input
transformation matrix has been changed. Input related components in kwin
can connect to it to keep a copy of the input transformation matrix in
SeatInterface in sync. Under the hood, the new signal is just an alias
for the bufferGeometryChanged() signal.
The new signal can be useful if one wants to watch a toplevel for buffer
geometry updates. This can be especially useful for input related code
because the position of the upper left corner of the main surface is used
to compute the input transformation matrix.
Currently, the test passes because the activities controller doesn't
have enough time to fetch all activities. So, the test client won't be
placed on the current activity.
Since the Workspace is now created before starting the Xwayland, we now
spin the event loop, which allows the activities controller to fetch the
list of all activities and so the test client will be placed on the
current activity, i.e. client->isOnAllActivities() will no longer return
true.
This change fixes wrong assumptions in the test and makes it robust.
Sub-classes of the AbstractClient class need a valid instance of the
Workspace class to function as desired. We should not create xdg-shell
clients until the workspace is created.
The new signal is emitted when the Application has fully been initialized.
It allows us to change the startup sequence, for example create workspace
before starting the Xwayland server, without making any adjustments in our
test suit.
It was called twice once with and without X as our implementation of
setRootInfo() missed some calls.
This was done to avoid a bug as setRootInfo() didn't update everything.
This patch aims to resolve that at the root cause.
I tested the original conditions of the patch with an empty kwinrc and a
file in /etc/xdg/kwinrc setting desktops to 2 and everything loaded
correctly.
Don't give the InputConfig a separate config instance. I've seen it
being changed after having initialized the xkb instance which would
break the shared instance.
Using a simple config rather than reading the configuration from
the actual code-path shouldn't make a difference as a test it will be
using ~/.qttest which should be cleaned upp
We may call setActive() on a window that is being deleted. We cannot
guarantee that at that moment the X11 window or the Wayland surface is
still valid. So, the best course of actions is to do nothing.
BUG: 424255
