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.
A new enum is introduced which defines all the buttons known to KWin.
The defaultTitleButton methods return a list of DecorationButtons instead
of a string which needs to be parsed by the decoration. The same for the
actual title buttons. The reading/storing of the buttons is unchanged,
that is the same characters are used and mapped to the button types.
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.
With this attribute set the QPainter on the widget() never gets active
in non composited rendering and thus the decoration does not get rendered
at all.
For this KDecorationOptions becomes a QObject. The changed flags from
updateSettings are removed. Instead the method just emits the proper
changed signals.
This should allow better handling in the Factories.
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
REVIEW: 103948
BUG: 91703
BUG: 299245
FIXED-IN: 4.11
- The setting is ignored, the decoration always gets a "true" for it
- moving a maximized window requires breaking a "strong" snap (1/16 of screen height - unless you use quick maximization)
- all snapping is done towards the client, not the frame
- QuickTileMode is exported to the decoration (just as the maximizeMode) so that it can fix the bordersize alongside that.
With 4933f08ae49328e36e2654434d28917310882ee5 the KDecorationBridge
interface became public to allow Compiz to easily implement the class.
From a KWin perspective this change did not make much sense. The Bridge
is meant to be the interface towards KWin. It is an internal interface
and exporting it doesn't change the fact that it is internal.
The change got introduced in a time when it was still common to use
Compiz in the kde-workspaces. This has changed. None of the top ten
distributions on distrowatch are shipping the integration parts of Compiz
in an up to date version. Most distros are still on Compiz 0.8, which
requires manual patching to keep up with changes in the decoration API.
Distros on Compiz 0.9 are not shipping the KDE integration - this
includes Ubuntu.
Given this development it is no longer justified to have additional work
on KWin side and because of that the API which should be internal is
marked as internal again.
In case Compiz is still interested in providing the kde-window-decorator
the header file can easily be pulled from our repository. In addition
this patch includes a method
int decoration_bridge_version()
which returns the current bridge API version. Kde-window-decorator can
resolve this method and verify that the version is not higher than what
is supported. The version number is provided in kdecoration.h by the
define KWIN_DECORATION_BRIDGE_API_VERSION. We will increate the version
number once per release in case the bridge changed. 4.11 will have the
version number 1.
This change in behavior has been discussed and agreed in [1].
The change also unexports KDecorationBridgeUnstable. This class should
have never been exported, it was incorrect and the parent class had not
been exported anyway. This is just a note to indicate that it is not an
ABI break and there is no reason to increase the so number.
[1] http://lists.kde.org/?l=kwin&m=136335502805911&w=2
CCMAIL: compiz@lists.freedesktop.org
CCMAIL: dev@lists.compiz.org
REVIEW: 109536
A decoration can provide the AbilityAnnounceAlphaChannel in addition to
AbilityUsesAlphaChannel. If this ability is provided the decoration can
enable/disable the use of the alpha channel through setAlphaEnabled().
The base idea behind this mechanism is to be able to tell the compositor
that currently alpha is not needed. An example is the maximized state in
which the decoration is fully opaque so that there is no need to use the
translucency code path which would render all windows behind the deco.
In addition also the blur effect honors this setting so that behind a
known opaque decoration no blurring is performed.
Oxygen is adjusted to disable translucency in maximized state and Aurorae
is adjusted to allow themes to enable/disable translucency. For Plastik
translucency and with that also blurring is disabled.
REVIEW: 106810
This slot can be reimplemented by the decoration to return
the regions defined by KDecorationDefines::Region.
The only region defined initially is ExtendedBorderRegion.
This region specifies an invisible input region that can extend
both inside and outside the decoration.
The intended use case is to be able to have an active border
area that's larger than the visible borders.
The KDecoration library lives in libkdecorations/ now.
Installation pathes are unchanged, so this does not influence 3rd party
decorations.
The changes in the KWin main directory are required due to incorrect
includes.
CCMAIL: kwin@kde.org
