The config option got disabled during porting to kdecoration2.
This change re-adds the config option and adds a small config
interface for SVG based themes.
If the configured decoration plugin fails to load, we try to load
the default decoration plugin. If that also fails to load, we try
to load Aurorae, which is shipped with KWin, so the chances are
higher that it is available.
Also the checks in Aurorae are improved to fall back to the Plastik
theme if the selected SVG theme is not available.
BUG: 341014
FIXED-IN: 5.2.0
REVIEW: 121859
Paint is in the middle of the compositor rendering loop. Updating
the shadow at that point breaks KWin. Thus we delay the update to
the next event cycle. Obviously it would be even better to only
update the shadow if it changed, but that might be too expensive.
This brings back the configuration for decoration plugins. As a change
to the old variant the configure button is moved into the list view
together with the preview. It is enabled/disabled depending on data
provided by the DecorationModel. For a plugin the DecorationModel
queries for a boolean "kcmodule" key in the metadata. For a theme it
invokes the slot hasConfiguration with the theme name which returns
whether the theme provides configuration.
The actual opening of the configuration is triggered from the
PreviewBridge, which uses the existing KPluginFactory to load the
KCModule. The decoration plugin must provide the keyword "kcmodule"
for it.
So far Aurorae is adjusted and provides configuration for the Plastik
decoration. The interaction with the configuration module works, but
the configuration itself for Plastik seems to be currently broken.
KNewStuff is no longer hard-coded to Aurorae themes. Instead the
availability of KNewStuff is derived from the available plugin
metadata. If the section org.kde.kdecoration2 contains a key
"KNewStuff" it's value is interpreted as the knsrc config file name.
If there is at least one plugin with such a key KNS gets enabled.
If there are multiple plugins providing KNS support the download
button is turned into a button with a connected menu and each menu
entry points to one of the available resources. Of course this is
not optimal, but KNS doesn't allow the combining of multiple config
files.
QQuickRenderControl brings a few advantages for the usage in Aurorae:
* can create an offscreen window
* eliminate the need for mutex as we control the rendering
* control the tear down of the QML scene (no more crashes in Qt)
In future we can further improve this, by sharing the context, so
that we can use the FBO texture directly. But this first needs
some more work in KWin core.
As we don't hard depend on Qt 5.4 yet it's using ifdefs. Once we have
Qt 5.4 the old code will be removed.
Adjust all components to use the QSharedPointer. Aurorae obviously has
to create a QSharedPointer, Shadow holds a QSharedPointer for the
DecorationShadow (advantage: is kept when the Decoration is destroyed),
and the KCM needs to add a property on PreviewItem to get access to the
Shadow. It's no longer a Q_PROPERTY on Decoration and we cannot re-add
it as a dynamic property (cannot be read from QML side).
* 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
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.
