Like with WindowSwitcher the configured value might be for the
look and feel package and thus we should first try to locate it
from the look and feel package.
Following features are supported:
* finds all plugins
** finds all themes for a theme-engine plugin
* renders previews for the plugin/themes
* loads currently used plugin/theme
* saves selected plugin/theme
* triggers config reload in KWin
Following features are currently not supported:
* Search
* Plugin configuration
* GHNS
* Button configuration
* Aurorae needs to pass QVariantList args to parent Decoration
* DecorationBridge implementation needs to be a KWIN_SINGLETON
* DecorationBridge needs to be passed with args to created Decoration
We assume the configured layout name is a look and feel package. Thus
the Switcher is located at contents/windowswitcher/WindowSwitcher.qml
of that package.
REVIEW: 120849
Currently just opening the Desktop Effects KCM loads QtMultimedia which
in turn loads gstreamer 0.10. If one opens any other KCM in
systemsettings and changes without applying the change, the window
freezes when the warning dialog gets shown, because the warning message
pulls in Phonon with maybe the Gstreamer backend which uses
gstreamer 1.0. This is bad, bad and breaks everything.
By using a Loader the problem scope gets reduced. It still happens but
only if one actually watches a video. Only opening the KCM doesn't
trigger the problem any more.
REVIEW: 120842
The idea behind the ThemeFinder is to expose a way for a configuration
module to find all themes. The API is not yet finalized, thus it's just
a QObject with a Q_PROPERTY themes of type QVariantMap with key being
the user visible name and value being the internal theme name.
The ThemeFinder will have to be moved to KDecoration library.
The json metadata provides a "themeListKeyword" which is used as the
keyword to the KPluginFactory.
DecorationShadow is supported through using the padding values. The
window becomes larger by the padding and gets positioned accordingly.
This requires to translate all mouse events.
The DecorationShadow is just using the complete image, which is kind of
a memory waste, but at least the SVG based Aurorae doesn't provide us
better information (might be added, but would probably need changes in
the theme).
For switching back to non-compositing we recreate the QuickWindow. It's
not fortunate, but as long as we do not yet have the render control it's
needed.
The port to KDecoration2 means quite some changes in the way how Aurorae
works. First of all: the theme to load is passed to the Deocoration ctor
and not searched for by Aurorae itself.
The rendering mechanismn didn't change significantly yet. It's still
rendering to an FBO and passing the image on. This needs some further
work as KDecoration2 does not support the padding any more. So all
themes using shadow are currently broken.
Another big change is the way how the rendering scene is constructed
and used. KDecoration2 doesn't want the the Decoration to be a native
window. But for being able to render a QtQuick scene at all we need a
QQuickWindow. Thus it creates a window parented to the decoration id,
but not accepting any input event. Input is nowadays controlled from
the outside: events are passed into the Decoration, so we don't want
the QtQuick window intercepting events.
In case of non-composited the normal FBO mechanism doesn't work and
Aurorae just renders to the QQuickWindow directly. This could use
some optimization in the decoration renderer in KWin core to not even
try to perform the normal rendering. On the other hand it's probably
too much a hassle for the use case.
The rendering architecture might hopefully be improved with Qt 5.4
and the new QQuickRenderControl class.
The QQuickWindow also exposes a problem for preview in the
kdecoration-viewer and the future KCM: we don't want a different
window, but best would be to get to the QML scene directly. A small
hack is added to have the previewers set a "visualParent" which Aurorae
uses to parent the QML scene to without the need to create a
QQuickWindow.
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".
KWIN_HAVE_EGL was set to EGL_FOUND which doesn't make sense as EGL is
marked as a runtime dependency. Instead a new build option KWIN_BUILD_EGL
is added defaulting to ON. If set to OFF neither the X11 nor the Wayland
EGL backend are built.
CCBUG: 340171
As we use epoxy we don't need them any more. KWin compiles, links and
runs just fine without ever trying to find OpenGL or OpenGLES.
BUG: 340170
FIXED-IN: 5.2.0
