* 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.
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 Text.horizontalAlignment property expects AlignHCenter instead of
AlignCenter. By not using AlignHCenter the centering broke when a window
got maximized.
It's possible that the rendering thread is still writing to the
buffer and if we destroy the buffer before it's finished KWin is going
to crash. So let's mutex lock the dtor to ensure that the rendering
thread finishes before we tear down the client.
BUG: 336950
Seems like porting to new infrastructure was incomplete. The
MaximizeRestore button consists of two buttons on top of each other with
an own mouse area in each and both always visible. This means the restore
button was stealing the mouse events of the maximize button breaking
maximization.
The solution is to have an additional MouseArea which controls the whole
button making the two button types just visualization.
The position passed to core didn't take care of padding and that position
passed to decorationPos caused completely broken resize/moving behavior.
E.g. resize was started where it should have been moving, or jumping of
position when starting moving.
REVIEW: 118803
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...
Qml based Aurorae themes can provided a ui file which gets loaded at
runtime. Obviously such a ui file is not translated. This introduces
quite a hack to load the translated strings.
First of all a new property is added to the service file for
specifying the translation domain to be used for the config UI. If
such a translation domain is set we extract all string properties of
the loaded UI and pass them through ki18nd.
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
* A KDecoration needs to include json metadata
* A KDecoration needs to be installed to kwin/kdecorations
* Aurorae and Oxygen adjusted
* kcmdeco locates all decorations through the KPluginTrader
* libkdecoration uses KPluginTrader to find the plugin
* config plugins also need to include json metadata with
X-KDE-PluginInfo-Name being the same as the decoration
* config plugins need to get installed to kwin/kdecorations/config
* kcmdeco locates the config plugin for a deco through the name
and KPluginTrader
REVIEW: 116765
Looks like this completely broke in Qt. The groups are all placed at
0/0 if there is an animation defined and the complete layout is broken.
The animation is not that useful in fact so no big loss.
The connect is from the KDecorationOptions which lives longer than the
factory, thus the lambda might be invoked after the Factory got
destroyed. Adding the context object protects against that.
To increase consistency with other decorations and because it changes
the behavior of the menu button in an unexpected way we default to
double click menu button doesn't close the window.
BUG: 331462
FIXED-IN: 5.0
REVIEW: 116716
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
strace -e open kate |& grep -v NOENT | grep oxygenrc | wc -l
went from 8 to 4
(and when looking for kdeglobals, from 13 to 11)
There's still a lot of work to be done in that area...
(within KConfigSkeleton, and probably kdeplatformtheme)
REVIEW: 115964
The reason for this change is that the default ctor of KWindowInfo
creates a broken object. Calling any method in it will result in a
crush. Thus it is scheduled for removal in kwindowsystem framework
causing this code to no longer compile.
The solution is to use a pointer and set it to null as long as the
window has not been detected yet.
This is the same change as done for kcm kwinrules. And here we se
why copying code is bad ;-)
They have been unmaintained for a long time and nobody stepped up to
port them to the changes in the decoration API. If at some time someone
wants to bring them back it's still in the git history.
They're not needed anymore, and break my build directory from time to time.
If this commit breaks your compilation, clean your build directory (or at
least the plasma and kwin subdirectories).
[Common]
UseBackgroundGradient=true
Option is hidden (no UI element) because of string freeze
Also removed decoration blend style option.
Background gradient is now always decided based on window flag.
CCBUG: 273423
Background gradient is now always decided based on window flag.
CCBUG: 273423
Added option in oxygenrc to disable window background:
[Common]
UseBackgroundGradient=true
Option is hidden (no UI element) because of string freeze
Also removed decoration blend style option.
Background gradient is now always decided based on window flag.
CCBUG: 273423
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
Defines the DecorationButton type in DecorationOptions (needs to be
re-defined due to QML limitations) and exports the buttons as a
QList<int> property (again QML limitations).
All QML files are switched from string to the new enum type.
There is no difference between Oxygen and default KDecoration, so
it's not needed. It's also conceptionally wrong: decorations should
not be able to change the global default.
Fixes incorrect button color. DecorationOptions and PlastikButton are
both connected to decoration.active and the button gets invoked first,
thus the titleBarColor is still for the previous state. This was fun!
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.
libkdecorations is part of kde-workspace so calling find_library() cannot
work on a clean build since it has not been installed yet. CMake knows
about it anyway since its part of kde-workspace, so it can use it without
finding it.
CCMAIL: hugo@oxygen-icons.org
