The hack used to be used to hide windows before they get embedded into
another window. This has been wrong on multiple levels:
1. it does not belong into a window manager - the window should take care
of this by itself
2. Window title is not a proper way to identify windows
3. Using D-Bus to inform an X11 window manager about windows which should
not get managed is rather strange
4. The hack only works with KWin, but not with any other X Window Manager
5. Windows identified with this hack still appear in Alt+Tab, that is
they are managed after all. Only a flicker is suppressed
6. Such windows are shown in the taskbar which nicely illustrates how
wrong a D-Bus call to the window manager is
That the hack has been introduced for Java Applets in KHTML also shows
that this is wrong. Why does Gecko and WebKit not need such a hack? Why
is KHTML tied so closely to X11 and KWin? Having a hack for a technology
which is obsoleted (Java Applets) and shouldn't be used due to security
issues is another reason to no longer support this hack. This usage has
been removed from KHTML as of 67939b1 of kdelibs git repo.
REVIEW: 109450
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
Following the approach to move out of Workspace what doesn't belong into
Workspace Appmenu support goes into an own class.
This also has the advantage of better compilation with Qt 5 as moc seems
to dislike ifdefs in the slot definitions.
REVIEW: 109497
according to NETWM spec implementation notes suggests
"focused windows having state _NET_WM_STATE_FULLSCREEN" to be on the highest layer.
We'll also take the screen into account
The user set stacking (being raised) is not considered by the spec note
This behavior is also suggested by an old comment in activation.cpp, void Workspace::setActiveClient()
BUG: 296076
CCBUG: 224600
REVIEW: 109572
FIXED-IN: 4.11
Should shaded windows be iconic?
I don't know. Apparently nobody does. (google found me discussions but no conclusion)
OpenBox, Metacity and Compiz set shaded Windows iconic, Sawfish and IceWM don't.
Either way kwin presently sets shaded windows iconic when you map them (client.cpp, void Client::map(allowed_t)) so to remain consistent with ourselves and half of the other WMs i set it.
Otherwise it should not be set when unshading a window
(no justification but noteworthy: the bug reporter seems to intend to pause expensive painting when the window is iconic and in that regard it's oc better to have it for shaded windows)
BUG: 317025
FIXED-IN: 4.11
REVIEW: 109593
Remove support for OpenGL compositing without using a composite
overlay window. With this change kwin now also requires a
double-buffered framebuffer configuration.
glXCreateNewContext() is supposed to return NULL on failure, so let's
assume that it does. Don't try to create an indirect context when
creating a direct context failed. glXCreateNewContext() should return
an indirect context when a direct context cannot be created.
Use glXChooseFBConfig() instead of glXGetFBConfigs(), and prefer
the first usable configuration instead of the last.
Also rename initBufferConfigs() to initFbConfig().
Noticed this one during test compile against Qt5 as QX11Info is no longer
exposing appVisual. Using the visual from root window which works just
fine for this use case.
REVIEW: 109411
Tried to build KWin with enable final: it doesn't work. So if nobody uses
it, we don't need it in the CMakeLists to make it work.
Also it's removed in KF5 which means that removing it right now removes
differences in the build system.
REVIEW: 109357
Adding a new property on whether we want animations based on whether we
are on raster or with Compositing. The property is constant as the deco
gets recreated on compositing change state anyway.
REVIEW: 109456
BUG: 314532
FIXED-IN: 4.10.2
If a KWin script uses a ThumbnailItem which gets created before the
Compositor is fully initialized the thumbnail is not shown at all because
the connect to windowAdded etc. will never happen.
Therefore connect to Compositor::compositingToggled to re-connect
whenever the compositing state changes.
REVIEW: 109310
Since color correction got pushed merged in the Lanczos Filter is only
created for OpenGL2. Which means the complete ARB shader code path has
been dead since 4.10 anyway.
REVIEW: 108856
