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. To ensure that this doesn't fail
badly an assert is added to the getter in DetectWidget.
This was missing from what is available in KWin core. The brightness and
saturation are implemented using a custom shader which uses the same
logic as what we use in the scene shader.
We are only rendering an image, so it's better to load the image into a
texture. This allows to properly scale the example preview which
magically fixes all the layouting problems which used to be there.
Needs to implement a dummy switcher item. As the root item of the
switchers are no longer QQuickItem derived it cannot use a QQuickView.
Instead a component gets created and the switcher is just shown on the
primary screen. It's a more appropriate preview now which is not
put into a dialog window.
To make it more realistic (and to be able to dismiss it) the preview
grabs keyboard and mouse and closes itself if escape, return, enter or
space is pressed.
As well clicking outside the preview window closes the preview.
Instead we generate an export header for kdeinit_kwin and use it
to declare the KWIN_EXPORT. With this change our libs don't include
any KDE4Support headers any more. One step closer to no KDE4Support.
The ::palette() in KDecoration and KCommonDecoration returns the
QPalette the decoration should use for the decorated window. The
call delegates into the bridge and KWin core might provide a special
QPalette for a given Client depending on the _KDE_NET_WM_COLOR_SCHEME
property.
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
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.
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.
