In case that the window operation results in destroying the window
decoration we need to have the menu closed before the deco gets
destroyed. Otherwise Qt crashes.
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
For all the decoration updates called from Client into the decoration we
also have a signal being emitted. So turning the pure virtual public
functions into slots means we can just connect our existing signals and
get rid off the deep function calls.
The keepAbove/Below signals are changed to take a boolean argument as
needed by KDecoration and a few emitted signals are moved to a better
fitting location.
REVIEW: 110335
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
Many headers included KLocale to use i18n and co. But those methods are
defined in KLocalizedString and not in KLocale.
With KF5 klocale.h does no longer include KLocalizedString causing lots
of compile errors.
BorderNoSides is what is known from Oxygen as "No Side Borders". The name
should indicate that there is only a border at the bottom. BorderNone is
a mode with no borders at all.
The new enums are added to KDecoration and the KCM so that all decos can
make use of it.
Aurorae is adjusted to support the new sizes for QML themes (it breaks
the old svg based themes) and Plastik makes use of it, by rendering a
one-pixel border around the window, which illustrates that it's still up
to the decoration to decide how to make use of the setting.
REVIEW: 108164
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
Nobody is interested in whether the Abilities are supported.
There is one method in KWin core checking for the colors
supported by the currently loaded decoration:
Workspace::decorationSupportedColors
This method is not called from anywhere inside KWin, but is
part of the D-Bus interface, though nobody in KDE's repository
is calling it [1].
As it is part of public API the Abilities are only deprecated
and scheduled for removal with the next big break.
[1] http://lxr.kde.org/search?filestring=&string=decorationSupportedColors
REVIEW: 105785
if one clicks very fast, the timeout will coincident with the
second downtime (between press and release) what was used to be
interpreted as "still down"
BUG: 305738
REVIEW: 106227
FIXED-IN: 4.9.1
As discussed on the mailinglist [1] the tiling support is
removed from KWin. The main reasons for this step are:
* it is unmaintained
* it is a mode not used by any of the core KWin team
* original developer said at Akademy 2012 that he is not
interested in picking up the work again
* tiling has quite some bugs, e.g. multi screen not supported
* is conflicting with other concepts in KWin, e.g. activities
There is ongoing work to get tiling supported through a KWin
script, which is a preferred way as it does not influence the
existing C++ code base.
[1] http://lists.kde.org/?l=kwin&m=133149673110558&w=2
BUG: 303090
FIXED-IN: 4.10
REVIEW: 105546
The window menu is shown after a strong click on the menu button.
This makes close by double click on menu button working correctly.
A single (strong) click will open the window menu, a double click
will close the menu. A triple click is no longer required.
REVIEW: 103995
BUG: 157184
FIXED-IN: 4.9.0
