Given that the wayland protocol does not have window positions a recent
change to Qt development branch avoids having a mismatch of positions
and tells client code the window is at the topleft of the screen. This
fixes multiple bugs.
Unfortunately this breaks a few usages within plasma where a
side-channel sends that absolute positional information over a bespoke
protocol. Currently we proxy this all through QWindow geometry where the
new Qt behaviour will throw is askew.
Whilst our longterm plans are to find future options away from the
plasmashell protocol we may as well have our Qt6
build work given the patch is trivial and harmless.
It also allows for potential backporting if our software is
already secured against issues. Hence the cherry-pick.
QCursor::pos does not work under Wayland. So use active output from KWin to
determine startup screen. This will also honor the 'Active screen follows
mouse' option from Window Behavior (also under X11).
Depends on KWin merge request https://invent.kde.org/plasma/kwin/-/merge_requests/2209
BUG: 427069
FIXED-IN: 5.25
When calling cleanUpComponent KGlobalAccel checks if there are no
shortcuts active, otherwise it will refuse to clean the component.
For a desktop file component (aka KServiceActionComponent) all
shortcuts are deactivated inside cleanUpComponent. For a regular
Component we have to do this manually.
If a QAction is destroyed, KGlobalAccel will automaticaly set it
to inactive. To prevent this put them on the heap and intentionally
leak them as it did before.
CCBUG:437364
We got some reports that the update did not work correctly.
The kconf update daemon watches for new files so we should
rename the file in addition to changing the IP.
Because we have changed the name of the desktop file, this also
changes the name of the kglobalaccel component. I have adjusted the program so
it checks which of the two old components is active and then sets the shortcuts
on the new one. I have opted for this because we cannot guarantee the order of
update scripts.
This script copies the old history to each activity.
This way the user has the previous history in each activity.
Also the launch counts get copied to the new location.
The two ways of disabling session management have the same impact on the
session being saved, but there is one behavioural side-effect that
turned out to be less ideal.
By disabling completely we don't follow the session manager telling the
application to quit. That's not something needed with the systemd boot,
but for the legacy boot effectively we were just closing applications by
ripping the X connection away from under them.
Some applications are bad at handling this and this led to a bunch of
crashes or dangling processes at logout.
This reverts commit 9be7dedb87.
CCBUG: 424408