Fixes regression introduced with 90a6814: we may not queue a signal
taking a pointer to a ShellClient as the ShellClient might be destroyed
before the queued signal is delivered.
The idea for the queued signal was to ensure that the size is set when
windowShown is emitted - this can also be achieved by first updating the
size.
When a ShellClient is added and it's not internal, it get placed just
like any other Client. This needs to happen after the initial size is
determined.
Please note: this breaks the positioning of popup windows (e.g. menus)
as they are placed like any other Client. This needs proper popup support
which right now does not yet exist and thus is not much difference to
before.
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
