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.
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
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).
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.
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.
Martin Gräßlin
l10n daemon script
David Faure
Marco Martin
Aleix Pol
Matteo De Carlo
Martin Klapetek
Jacob Logan
Eric Newberry