It's possible that the Workspace doesn't get created at all (e.g.
Xwayland failed to start). In that case we must ensure to not call into
Workspace calls during tear down.
If startup fails and there is no Workspace the Compositor was destroyed
as a child of Application with the result of being destroyed after the
Wayland server resulting in a crash.
If the Workspace gets created the Compositor will be destroyed by the
Workspace, so there's no need to destroy it early.
The QtWayland QPA plugin does not create windows with
X11BypassWindowManagerHint which means that KWin's internal windows are
not shown at all. Even worse in QtQuick it can result in a freeze due to
blocking wait for a frame rendered which can just never happen.
As windows could be created by e.g. scripts or look and feel packages we
cannot ensure that the flag will never be set in source code.
Thus we use ApplicationWayland::notify to filter for Show events and
check whether the window to be shown is bypassing window manager hits.
If it is, we unset the flag, destroy the window and show a new one.
According to spec eglQueryWaylandBufferWL returns EGL_FALSE if
EGL_WAYLAND_Y_INVERTED_WL is not supported and in that case we should
treat it as af the value were set to EGL_TRUE.
The code didn't use QProcess as in the early days of main_wayland.cpp
Xwayland had to be started before the QGuiApplication was constructed.
As this requirement doesn't exist any more we can use QProcess and
improve the interaction by e.g. provide useful error messages if
Xwayland couldn't be started.
We need a shared window id in some way to e.g. properly support TabBox.
Though I do not like that the return value is xcb_window_t. This should
be either changed or a new "generic" windowId needs to be introduced.
Adds all internal ShellClients into a dedicated list. This ensures that
we don't perform "normal" window management on them.
In addition we add them to the top of the stacking order. This restores
behavior as it is on X11: internal windows are using BypassWindowManagerHint
and thus on top of everything.
The internal used window Id consists of two parts identifiying the
Client and one identifying the Surface. That is the first 16 bits
are set to the ClientConnection, the last 16 bits are taken from
the Surface id. As the Surface id is 32 bits, but we only use 16 bits
there is a chance of overlap. So this might need some improvement.
If we get an Expose event for any QWindow we need to ensure that all
wayland events on both client (Qt) and server (KWin) side are dispatched.
Otherwise it could happen that Qt starts rendering although the last
frame callback has not yet been emitted, causing the main gui thread to
be blocked.
othrwise closing a keepabove or desktop group
window would activate some random window and break
the state as a side-effect
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
... not them becoming visible.
Latter doesn't work for most cases (unminimizing)
for obvious reasons (they're not minimized) and
when a new window is mapped, the focus stealing
prevention seems a good filter
(if it's not good enough to gain the focus,
it's not good enough to break the state either)
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
Windows that "belong" to the desktop are
kept visible and do no break the state on
activation/mapping
REVIEW: 123783
CCBUG: 346837
CCBUG: 346933
CCBUG: 347212
If the ShellClient got created for a Qt internal window, we try to
find the QWindow and if we get one, we use the geometry directly as
it got set by KWin in the first place.
Also a windowId() is added to ShellClient which can be used by the
effect system to find an EffectWindow. If it's an internal QWindow
we just use that window id. For other clients we still need some
smart solution.
