A decoration plugin can indicate that it supports themes. For this
the decoration plugin needs to specify in the org.kde.kdecoration2
group of the JSON meta data the following:
themes: true,
defaultTheme: "nameofDefaultTheme"
If the themes key/value pair is present and set to true KWin will
read the entry "theme" in the [org.kde.kdecoration2] group with the
value of defaultTheme as the default value.
The read value (if there is one) is passed to the created decoration
in the QVariantList. The QVariantList contains a QVariantMap as first
entry and the theme name is passed for key "theme".
Required to stop and disconnect the timer. Otherwise it's possible
that the render is invoked after the Client got destroyed. This
happened for example with e.g. opening Kickoff.
Uses the QuickTileMode of the Client to indicate which borders to
remove. This could be extended to be in general when a window borders
the screen edge and not just for quick tile mode.
So far the DecorationRenderer got destroyed and recreated after
the signal compositing toggled was emitted. But that's too late for
e.g. the OpenGL Textures to be destroyed. So lets trigger the destroy
directly in setup/finish compositing. The new renderer will still be
created after the compositing toggled is emitted - we don't want to
have it recreated for the still active compositer type.
The Renderer gets reparented to the Deleted. While passing it to
the Deleted the Scene's implementation can ensure that the buffers
are up to date. After passing to Deleted it's no longer allowed to
call the render method.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
