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.
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.
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.
The KWin::Borders element is provided by an extension plugin. The reason
for that is to be able to use it from e.g. the kcm or Plasmate without
needing to compile the code in.
But this results in Aurorae itself not being able to access the element.
The solution is to first load our decoration plugin and afterwards
register the borders element again with the version compiled in from
Aurorae.
With that we can now read all borders and paddings without using
properties. Also we could connect to change signals and have the borders
and padding handling completely stateful. Might be an idea for extending
the decoration library...
This seems to fix the crash which could happen when closing a window. At
least the kwindowsystem unit tests no longer crash KWin (it was very
reliable before).
BUG: 332091
This simplifies the plugin loading. Decorations just have to use
K_PLUGIN_FACTORY to specify how the KDecorationFactory needs to be
created. The KWIN_DECORATION macro is adjusted to generate the
boiler plate code, but it now needs to specify the name for the
pluginfactory and the KDecorationFactory.
This also transits the decoration abi version check to use
K_EXPORT_PLUGIN_VERSION which also simplifies the loading.
As a result the complete canLoad handling in DecorationPlugins is
removed.
REVIEW: 115930
This is a temporary solution! A proper solution needs changes in
libkdecoration and paint redirector.
The hack redirects the rendering into an FBO. After each rendering we
get a QImage from the FBO and store that in a buffer. As we unfortunately
do not know what changed, we schedule a complete update on the deco's
widget. Once we get the paint event we just render the buffer on the
widget. And thus we have copied the content to a place where it
integrates with the paint redirector.
As already written, this is a horrible hack and I'm not proud about it.
There are just too many copies involved.
So how to improve?
* deco should be able to just provide a QImage to the PaintRedirector
without the paint to the QWidget.
* only do the FBO -> QImage step if it is needed by the compositor, that
is compress the events
* for OpenGL compositing it would be totally awesome if we could just
make the contexts sharing so that we can just reuse the texture from
the FBO directly.
Major transition to render using QtQuick 2. This means the actual
rendering needs a QQuickWindow which we embed into a QWidget container.
Not an optimal solution, deco API should offer to operate on QWindow.
For non-composited the decoration gets rendered but for composited
rendering the paint redirector is broken. There are no paint events on
the main QWidget to intercept and thus the redirection doesn't work.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
The property is of type bool and maps to isMaximized and not to
maximizeMode.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Also isOnAllDesktop property is added using the same changed
signal as desktop property.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Adding a new property on whether we want animations based on whether we
are on raster or with Compositing. The property is constant as the deco
gets recreated on compositing change state anyway.
REVIEW: 109456
BUG: 314532
FIXED-IN: 4.10.2
The Borders element provides the four properties:
* left
* right
* top
* bottom
And is used directly in Decoration for all the different kind of settings
following this pattern:
* normal borders
* maximized borders
* padding
* extended borders
These properties replace the existing used borderLeft & co. This makes
the code in the C++ side easier as the various border elements can now be
read with a shared implementation.
The Borders provide some convenient methods to set the sizes of the
borders. E.g. it's possible to just set the side borders to a specific
value. This should simplify the implementation of the no-side-borders
feature in new decoration.
The aurorae qml and plastik are adjusted to use the new way. Existing
3rd party decorations would break, but there's a good reason why there's
no documentation for QML based decorations ;-)
REVIEW: 108436
Aurorae Themes can make use of the extended borders feature to allow
resizing outside the window decoration area. So far only Plastik makes
use of it in the Tiny border case.
This should be extended in future by adding generic NoSideBorders and
NoBorders sizes as used by Oxygen.
FEATURE: 308992
FIXED-IN: 4.11
REVIEW: 107936
A decoration can provide the AbilityAnnounceAlphaChannel in addition to
AbilityUsesAlphaChannel. If this ability is provided the decoration can
enable/disable the use of the alpha channel through setAlphaEnabled().
The base idea behind this mechanism is to be able to tell the compositor
that currently alpha is not needed. An example is the maximized state in
which the decoration is fully opaque so that there is no need to use the
translucency code path which would render all windows behind the deco.
In addition also the blur effect honors this setting so that behind a
known opaque decoration no blurring is performed.
Oxygen is adjusted to disable translucency in maximized state and Aurorae
is adjusted to allow themes to enable/disable translucency. For Plastik
translucency and with that also blurring is disabled.
REVIEW: 106810
When the decoration is reset a signal is emitted that the config
might have changed which the decoration can connect to for
reloading its configuration. For this an invokable method is
added to Aurorae allowing to read a config value which just
returns the QVariant.
Proper support for border sizes are added by providing the enum
in DecorationOptions, so that QML themes can use the enum values
to decide which border size to use.
The kcm is adjusted to also support these config mechanisms and
to properly load and save the border sizes for QML based themes.
The generic QML components from Aurorae are split out into an
own declarative plugin. In addition two new helper classes are
added to this plugin:
* A ColorHelper to map a few function of KColorSheme and making
it possible to actually work with colors in QML. The need
emerged from trying to port Plastik to QML which makes strong
use of color shading.
* A DecorationOptions class which is a wrapper around KWin's
KDecorationOptions but in a more useable way for QML. The
various options are provided as properties and the value of
the properties changes automatically depending on whether the
decoration is active or inactive.
Aurorae itself is not yet adjusted to these changes, but it
should also be adjusted as some of the options are currently
exported in the factory and the factory is injected into the
Aurorae QML decoration.
The result of maximizing a window might be the decoration
going away. Because of that we need to delay the handling of
maximize and title bar double click by one cycle as had been
done for other close operations in 0fea5325
BUG: 304870
FIXED-IN: 4.9.1
REVIEW: 105961
Unfortunately QtQuick 1 does not provide a way to receive Wheel
events. But the window decoration needs to pass wheel events on
the titlebar to KWin core.
In order to process also Wheel Events in Aurorae an event
filter is installed on the widget and in case the mouse positon
is on the title bar the titlebarMouseWheelOperation is invoked.
BUG: 304248
FIXED-IN: 4.9.1
REVIEW: 105801
This is an issue we already had in the past with Aurorae. When
closing a window the graphics scene crashes because the deco
gets destroyed before the code in the graphics scene finished
the execution.
With the port to QML this seemed to be fixed unless as it turns
out it throws an XIO error on closing:
fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
This can be triggered using glxgears. Closing glxgears would
reliable crash Aurorae. To circumvent this issue we have to
delay the close by one event cycle using QMetaObject's
invokeMethod with a Qt::QueuedConnection.
This has also to be done in the useractions menu as the menu
is still open when the window closes causing the same problem
inside Aurorae.
BUG: 303450
FIXED-IN: 4.9.0
Reviewed-By: Thomas Lüking
