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.
All the rendering to QPixmap code in the Model and the Preview is
deleted as it's no longer used.
The model still has the plugin for the border size functionality.
This probably needs a change in the API to make it completely bound
to the decoration and not a global thing.
Using a QQuickPaintedItem for the rendering. The item gets the library
name from the model and loads the decoration with its own decoration
plugin. Thus each preview has its own plugin which eliminates the need to
constantly recreate the decoration as it is done with the preview.
Having a QQuickItem gives new possibilities. The item accepts hover
events and forwards them as enter and leave events to the widgets inside
the decoration. By that the mouse interaction of e.g. Oxygen is still
functional. If the decoration uses the new update approach the bridge is
forwarding the updates to the item and triggering a repaint so we even
have animations in the preview although the widget is never shown.
A setMainWindow() method is added which behaves similar to
setMainWidget(). In addition a few convenient methods are added which
can be used by KWin core to show/hide the decoration without caring
whether the decoration uses a QWindow or QWidget.
KWin core can access the QWindow of the decoration instead of the
QWidget. This is a preparation step to allow QWidget based window
decorations without any QWidgets at all.
KWin core makes already use of this new accessor to get the window Id
which is also on QWidgets provided through the QWindow.
The PaintRedirector calls the new method KDecoration::render and passes
it's PaintDevice and the region to update to it. A decoration can
implement this method and provide an optimized implementation for the
painting which does not go through the deco's QWidget at all. In addition
the decoration can invoke an update() slot which will schedule a repaint
in the PaintRedirector and thus completely replaces the need for
intercepting paint events on the QWidget and also allows to add QWindow
based decorations in future.
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.
The QWidget of the window decoration is otherwise still thinking that
the button is pressed and waits for a release. Thus the next click on
the decoration doesn't trigger the move mode.
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
Adding a simplified logic to unload all effects directly in the
dtor. Looks like Qt didn't like our double traversal over the list
any more and was causing double deletions.
The xcb sync protocol is incorrectly defined (see [1]) which results in
xcb_sync_create_alarm not creating a valid alarm. To work around this
issue we only create the alarm without setting the int64 values. For
those we use the XLib XSyncChangeAlarm call after we verified that the
alarm got created. This unfortunately reintroduces linking against
libxext. But at least resizing works again.
[1] http://lists.freedesktop.org/archives/xcb/2013-June/008375.html
Need to change it anyway due to kded becoming kded5 and following
the suggestion by afiestas directly renaming to not use the kded
service.
Service: org.kde.kappmenu
Path: /KAppMenu
A declarative KWin script needs to register the QQuickWindows it is
using in the KWin object. This method ensures that the QQuickWindow
will destroy the platfrom window once it gets hidden. So the next
time the QQuickWindow is shown a new platform window is created.
As can be seen in the OSD this is not really nice, therefore a
KWin.Dialog should be created which takes care of these steps.
