GitLab

Our server announces the DpmsManagerInterface and in the DRM backend
we announce support for Dpms on the OutputInterface (if the Output
supports it) and we connect to changing Dpms requests.

use the new blur protocol to fetch information about the
region of blur behind to apply to windows like Plasma::Dialog
REVIEW:125017

No longer needed with our own QPA plugin.

This reverts 29c2ae57.

Our own QPA plugin shares the internal connection, so we don't need the
dedicated connection for the QPA any more.

Of course only works with internal clients.

Allows to interact with the Registry for the internal connection in
other parts of KWin and makes it possible to create more than just the
ShmPool for this Registry.

For Wayland clients we now are able to get shadows.

Internally this reuses large parts of the X11 implementation. This
could be improved to make the Scene's better aware of the Wayland
shadow, so that less memory is needed.

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).

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.

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.

This should be enough for libtaskmanager to manage the windows.

The unmap triggers a destroy on client side and also triggers the
automatic cleanup of the PlasmaWindowInterface instance.

With Xwayland clients it can happen that the window gets destroyed
before it ever got a surface (Qt 5's file open dialog being an example).

This change delays such clients till it got the surface, removing not
needed roundtrips and possible problems.

Creates a PlasmaWindowInterface for each AbstractClient and so far
passes caption and virtual desktop through.

So far this only allows to trigger show desktop functionality and exports
the state.

In future this should be restricted to just one dedicated desktop shell
process.

Input-method servers, like maliit, need to be known to KWin since KWin
needs to know about virtual keyboards. Virtual keyboards should be shown
as OSD layers, and they are one of the types of windows that actually
should be showable when the lock screen is active.

kwin_wayland --inputmethod /path/to/your/input-server

tries to start the input server. The input-server's window never gets
keyboard focus and is shown on top of all windows except for KWin's
internal clients.

If the ShellClient has a QtExtendedSurface it's closeable.

The PlasmaShell interface allows to create a PlasmaShellSurface for a
given Surface. Through this interface the Surface can request:
* a specific position
* a window type

So far only the window types Normal, Panel and Desktop are supported
which is a sufficient subset for getting plasmashell to work.

In future there should be security checks so that only the dedicated
desktop shell can bind these interfaces.

No longer needed as we install keymaps which prevents the crash in
QtWayland this version check worked around.

Fixes regression introduced with 90a68145: 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.

This simplifies the interaction: we know that the Surface is useable if
it got announced to the Workspace.

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 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.

QtWayland and mesa might dead lock KWin if we start rendering a QWindow
before Qt/Mesa got the last frame callback. They perform blocking wayland
event reading on the main gui thread which makes it impossible for KWin
to do the compositing and send the callback.

To workaround this problem we fake a frameRendered directly after each
damage event for a Qt internal window. Unfortunately this is not yet
completely sufficient, thus we also need to ensure that the wayland
events are processed before any events are processed which would cause
a repaint and block. Thus we first flush QtWayland's wl_display and then
our Server connection. If there were any damage events we can be sure
that the frameRendered is sent before Qt attempts to render.

QtWayland only creates popup windows if they have a parent QWindow or
if there is any window which had input. It's not enough to fake an
enter, it needs to be either a pointer button press or key press.

As KWin's useraction menu doesn't have a parent and we most likely
never send a pointer press to any QWindow it doesn't get shown. To
circumvent this we create a dummy window and fake a button press/release
on the window. After that Qt is tricked into believing there's a parent
window and shows the popup.

Faking the input is only done with at least Qt 5.5 as QtWayland crashes
on pointer event without a keymap being installed. As KWin does not yet
send keymaps we better disable the dangerous code path. With Qt 5.5 the
crash condition is fixed.

Similar to Surface: we ignore till we are all ready to go.

For other clients we are only interested in the shell surfaces.

Makes QtWayland way more happy.

The ShellClient is a Toplevel subclass for a
KWayland::Server::ShellSurfaceInterface. It gets created when a new
ShellSurfaceInterface is created and destoryed when it gets unmapped.

So far the usage is still rather limited. The ShellClient is opened
at position (0/0). While it's possible to pass pointer events to it,
it's not yet possible to activate it, so no keyboard focus.

This gives the backend more control without needing to provide all
information in Screens.

If Xwayland goes down it's better to abort than staying alive. If
Xwayland goes down the next roundtrip to X (most likely during call
to xStackingOrder) will just freeze completely, which is kind of the
worst as one cannot VT-switch anymore. So a clean abort is a bad but
better solution.

Not perfect but better than a hardcoded physical size.