5c3cd6f4bc
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. |
||
|---|---|---|
| .. | ||
| aurorae | ||
| CMakeLists.txt | ||
| Messages.sh | ||