The creation of PlasmaWindowInterface is moved from WaylandServer into
AbstractClient. This allows the sub classes to better control when to
create/destroy the Client.
For creation it's bound to becoming visible - that is Windows which are
only created but never shown are not announced at all.
For Client it's destroyed with the normal tear-down of a Client, for
ShellClient it's destroyed on unmapped (which also means a new one
will be created again in case of another mapping of the surface).
As a side effect, this works around the problem that ShellClients do not
yet get destroyed for QtWayland's menus (needs further investigation).
The problem with KToolInvocation is that it creates a dead lock on
Wayland in case kdeinit is not already running. It starts kdeinit
and does a QProcess::waitForFinished and our kdeinit needs to interact
with the wayland server. So dead lock.
As KRun also calls into the dangerous code path it's no option which
leaves us with QProcess to start the processes.
A nice side-effect is that we no don't need to link KF5::Service any
more from kwin_core. Now once Plasma and Notification don't use it
any more, it will be gone completely.
Overwrite the platform name through the environment variable and ensure
that the plugin is not picked in non-kwin Wayland sessions as that puts
kglobalaccel5 into a crash restart loop.
BUG: 349911
This is a temporary workaround for bug 349992 which causes freezes
during startup as kwin and kamd dead lock each other on DBus.
To workaround we don't call Activities::create and check in every
usage of Activities::self() whether the pointer is valid.
As a result kwin_wayland now starts pretty fast.
CCBUG: 349992
kdeinit_executable doesn't make sense in the case of kwin_wayland as
start_kdeinit_wrapper will be executed after kwin_wayland thus the
framework doesn't work.
The KGlobalAccelD which gets created by KWin needs a plugin for the
platform specific parts. This change introduces such a plugin. It's
linked against kwin so that it can integrate with the core.
On enable the plugin registers itself in the InputRedirection and
GlobalShortcutsManager checks the plugin whether a shortcut got
triggered.
As the loading of the plugin must happen after InputRedirection is
fully created a dedicated init method is added to InputRedirection.
REVIEW: 124187
Internally QX11Info::display() calls into QPA native interface and
tries to resolve the nativeResourceForIntegration for "display".
Unfortunately this key also exists in other QPA plugins, e.g. in
QtWayland.
Calling without a check on platform results on wayland qpa in
wl_display* being casted into Display*.
REVIEW: 124203
During cleanup the KWayland::OutputInterface is already destroyed before
we hit the cleanup code of DrmOutput. Thus guard with a QPointer to not
delete twice.
If none of the backend specific command line options are passed, we
try to autmatically determine the proper plugin.
1. if DISPLAY is set -> x11 backend
2. if WAYLAND_DISPLAY is set -> wayland backend
3. if compiled with libhybris and ANDROID_ROOT is set -> hwcomposer backend
4. if compiled with DRM -> drm backend
5. if nothing selected yet, fallback to fbdev
If an env variable is set outside of KWin (e.g. QT_QPA_PLATFORM) we
want KWin to pass the original env variable to the started process and
not pass none instead because it's one of KWin's special changed
variables.
Thus we take the environment before we adjust it and pass that to the
started processes with our own DISPLAY and WAYLAND_DISPLAY added.
Ensures that the PlasmaWindow gets destroyed together with the window.
Note: when a ShellClient gets unmapped the PlasmaWindow does not yet
get destroyed. It should probably get destroyed and recreated on next
mapping.
Logic similar to Client::takeFocus: if window is keep above or on
screen display do not break. Also if window belongs to the same
ClientConnection as a desktop window don't break.
If the icon doesn't have a name, we pass the generic xorg icon. Most
likely our xwayland clients won't have a theme name, so giving them
the xorg icon seems a good enough work around. If we would want to
pass the real icon for xwayland clients we would need a way to
serialize them which seems like quite some needless overhead for legacy
applications. Can be considered for the future nevertheless.
Prime target is to preserve the in-screen
condition of client AND window.i[1]
Atm. when the client is fully in sight
(but the window is not) - regardless of snapping
or screen change - a workspace update (screen change,
resolution change, adding/removing a strutting panel)
would allow the client to partiall escape screen bounds.
This is changed so that if the client is fully in sight,
it's kept fully in sight (but not the decoration)
If the entire window was fully in sight, it's also kept
(as is right now)
The code handles inner screen edges (if the client was in sight,
the entire window will be if we'd bleed to the other screen)
[1] I'd say that handling the client is more relevant,
but foresee more complaints if the window wasn't handled anymore ;-)
During that, i stumbled across some other issues.
- when a window centered on one screen is moved to a screen smaller
than the window, the window is shrinked to the dimensions of that
screen and now randomly touches eg. left AND right edge. When
moved back, the right and bottom edge were preferred
(to the window was "moved" into the lower right corner).
It's now kept centered.
- geom_restore was saved before keeping the window in the new
screen area (causing accidental drops on screen changes)
BUG: 330968
REVIEW: 122517
FIXED-IN: 5.4
Prime target is to preserve the in-screen condition
of client AND window.[1]
Atm. when the client is fully in sight (but the window is not) -
regardless of snapping or screen change - a workspace update
(screen change, resolution change, adding/removing a strutting
panel) would allow the client to partiall escape screen bounds.
This is changed so that if the client is fully in sight,
it's kept fully in sight (but not the decoration)
If the entire window was fully in sight, it's also kept
(as is right now)
The code handles inner screen edges (if the client was in sight,
the entire window will be if we'd bleed to the other screen)
[1] I'd say that handling the client is more relevant,
but foresee more complaints if the window wasn't handled anymore ;-)
During that, i stumbled across some other issues.
- when a window centered on one screen is moved to a screen
smaller than the window, the window is shrinked to the dimensions
of that screen and now randomly touches eg. left AND right edge.
When moved back, the right and bottom edge were preferred
(to the window was "moved" into the lower right corner).
It's now kept centered.
- geom_restore was saved before keeping the window in the new
screen area (causing accidental drops on screen changes)
BUG: 330968
REVIEW: 116029
FIXED-IN: 5.3
