Adds a section about screens to supportInformation containing:
* whether multi-head is used
* in case of multi-head the screen number
* the number of screens
* geometry per screen
That should hopefully end the two often asked questions about the user's
screen setup, especially if they say they use multi-head.
REVIEW: 108363
Main motivation for this change except the fact that it doesn't belong
into Workspace is that the screen edges got updated from within setting
the desktop layout which got removed with the introduction of the
VirtualDesktopManager.
The ScreenEdge now keeps some state to be able to correctly unreserve the
electric borders when changes in the configuration are performed. There
is still room for improvement as there are still some deep function calls
from within reconfiguring in Workspace.
REVIEW: 107493
Most recently used virtual desktop chain is only used in the context of
TabBox and therefore moved into this namespace. KWin uses one desktop
chain for each activity. This is mapped by having multiple DesktopChains.
In addition there is a DesktopChainManager which contains all those
chains which are identified by a QString.
The manager gets connected to the signals emitted by VirtualDesktopManager
for changes in virtual desktops and to signals related to Activities
emitted by Workspace. This means the manager is rather generic as it does
not depend on any other components.
The ownership for virtual desktops is moved from Workspace into a new
VirtualDesktopManager. The manager is responsible for providing the count
of virtual desktops and keeping track of the currently used virtual
desktop.
All methods related to moving between desktops are also moved from
Workspace to the new manager, though all methods related to Clients on
Virtual Desktops remain in Workspace for the time being. This is to have
the new manager as independent from KWin core as possible.
An rather important change for the handling of virtual desktops is that
the count and the id of a desktop is now an unsinged integer instead of
an integer. The reason for that is that we cannot have a negative count
of desktops as well as it is not possible to be on a desktop with a
negative identifier.
In that regard it is important to remember that a Client can be on a
desktop with a negative identifier. The special value for a Client being
on all desktops is handled by using -1 as a desktop. For the time being
this is not adjusted but instead of comparing the virtual desktop ids one
should prefer to use the convenient methods like isOnDesktop and
isOnAllDesktops. This would allow in future to internally change the
representation for on all desktops.
If a section of comments consists of a list of links and all are broken
it's a sign that nobody has used these comments for a long time...
REVIEW: 107933
OpenGL is properly working if there is a direct rendering context.
If LIBGL_ALWAYS_INDIRECT is set VirtualBox falls back to Mesa's software
rasterizer. So in order to get OpenGL the driver is now whitelisted in
the opengltest.
GLPlatform is extended to recognize the VirtualBox driver and has new
methods to report whether it is a virtual machine and VirtualBox. The
detection is rather limited as we don't get access to the underlying
hardware, so we do not know whether the features are really supported.
We need to trust the driver here in announcing the right extensions.
The driver does not provide glxQueryDrawable although it is part of
GLX 1.3. A hack is added in the glxbackend to set the function pointer to
NULL. This can unfortunately not be done in glxResolveFunctions() as
QueryDrawable seems not to be provided by an extension (at least not
listed in the OpenGL registry) and getProcAddress resolves a function but
it only prints an OpenGL Warning to stderr.
As a note: the driver reports that it is using XSHM for
GLX_EXT_texture_from_pixmap.
REVIEW: 106821
The main usage of ShaderManager::isValid was to have OpenGL2 specific
code pathes. Now we have an actual OpenGL2Compositing type and we know
that the ShaderManager is valid if we have this compositing type and we
know that it is not valid on OpenGL1Compositing. This gives us a much
better check and allows us to use the isValid method just for where we
want to check whether the shaders compiled successfully.
In addition some effects require OpenGL2, so we do not need to check
again that the ShaderManager is valid. Such usages are removed.
The CompositingType enum turns into flags and two new values are
introduced: OpenGL1Compositing and OpenGL2Compositing.
Those new values are or-ed to OpenGLCompositing so that a simple check
for the flag OpenGLCompositing works in case of one of those two new
values. To make the generic check for OpenGL compositing easier a method
in EffectsHandler is introduced to just check for this.
The scenes now return either OpenGL1Compositing or OpenGL2Compositing
depending on which Scene implementation. None returns OpenGLCompositing.
Two new interfaces are introduced:
* org.kde.kwin.Compositing
* org.kde.kwin.Effects
The Compositing interface is generated from scriptable elements on the
KWin::Compositor class and the Compositor is exported as /Compositor.
It provides the general Compositing related D-Bus methods like whether
the compositor is active and toggling and so on.
The Effects interface is generated from scriptable elements on the
KWin::EffectsHandlerImpl class and the instance is exported as /Effects.
It provides all the effects related D-Bus methods like loading an effect
or the list of all effects.
This removes the need to have all these methods provided on the global
org.kde.KWin interface. For backwards compatibility they are kept, but
no longer provided by the Workspace class. Instead a new DBusInterface
is generated which wrapps the calls and delegates it to one of our three
related Singleton objects:
* Workspace
* Compositor
* EffectsHandlerImpl
The Compositor class actually behaves like a Singleton so it should be
one. Therefore four static methods are added:
* self() to access the Singleton
* createCompositor() to be used by Workspace to create the instance
* isCreated() to have a simple check whether the Singleton is already
created
* compositing() as a shortcut to test whether the compositor has been
created and is active
The isCreated() check is actually required as especially Clients might
be created and trying to access the Compositor before it is setup.
The refactoring of Compositor starting with b1739c3 caused some
regressions due to variables in Workspace and Compositor not
being initialized. Furthermore there was a boolean logic error
in PaintRedirector causing the decorations not to paint.
BUG: 305875
For most actions where the compositor needs to perform an action
(e.g. scheduling another repaint) signals were already emitted.
So it's easier to just connect the signals to the Compositor
which in turn makes the code much more readable.
All signals are connected from the Workspace when either the
Compositor gets constructed or a Toplevel gets created.
The DBus signal which causes KWin to reinitialize the Compositor
is moved into the Compositor as everything can be handled from
there as well. This comes together with moving the restartKWin
functionality into the Compositor as it is only relevant there.
Restart will only happen if the wrong Qt graphicssystem is used
for the chosen compositing backend.
The Scene has always been created and destroyed inside what is
now the split out compositor. Which means it is actually owned
by the Compositor. The static pointer has never been needed
inside KWin core. Access to the Scene is not required for the
Window Manager. The only real usage is in the EffectsHandlerImpl
and in utils.h to provide a convenient way to figure out whether
compositing is currently active (scene != NULL).
The EffectsHandlerImpl gets also created by the Compositor after
the Scene is created and gets deleted just before the Scene gets
deleted. This allows to inject the Scene into the EffectsHandlerImpl
to resolve the static access in this class.
The convenient way to access the compositing() in utils.h had
to go. To provide the same feature the Compositor provides a
hasScene() access which has the same behavior as the old method.
In order to keep the code changes small in Workspace and Toplevel
a new method compositing() is defined which properly resolves
the state. A disadvantage is that this can no longer be inlined
and consists of several method calls and pointer checks.
All Workspace functions which were implemented in the file composite.cpp
were moved to an own class Compositor. The header entries were moved as well.
All functions calls are updated.
All methods and variables related to the User Actions Menu
(rmb window deco, Alt+F3) is moved out of the Workspace class
into an own UserActionsMenu class.
The class needs only a very small public interface containing
methods to show the menu for a Client, closing the menu and
discarding the menu. Everything else is actually private to the
implementation which is one of the reasons why it makes sense
to split the functionality out of the Workspace class.
As a result the methods and variables have more sane names and
the variable names are standardized.
REVIEW: 106085
BUG: 305832
FIXED-IN: 4.10
New "Move To Screen" menu is shown after the "Move To Desktop"
menu if there are multiple screens and the window can be moved
to another screen. Menu contains one radio button for each
screen.
Selecting an entry sends the Client to the selected screen.
BUG: 269207
FIXED-IN: 4.10
REVIEW: 106065
The supportInformation is extended to also read the properties
on all effects. In addition each effect can be queried just for
itself through D-Bus, e.g.:
qdbus org.kde.kwin /KWin supportInformationForEffect kwin4_effect_blur
All effects are extended to provide their configured and read
settings through properties. In some cases also important
runtime information is exposed.
REVIEW: 105977
BUG: 305338
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
New properties for the current activity and the available
activities plus related signals in scripts. Signals added to
effects.
BUG: 302060
FIXED-IN: 4.9.0
Workspace emits a signal when the initialization finished and
interested parties can connect to this signal to perform post
init actions. That is everything that does not have to be
performed to have a completely working Window Manager.
As an example loading the scripts is moved into this post init
phase.
REVIEW: 104580
Options loading is split into three parts:
* reparse configuration
* loading of non-compositing related options
* loading of composited related options not needing CompositingPrefs
At startup the reparsing of configuration is done through a Thread
to gain a little bit of less waiting.
Before something else accesses the KConfig for the first time we
wait for the thread to finish and perform the other two loading
operations of Options.
The settings depending on CompositingPrefs will only be invoked
if a compositor is going to be needed.
REVIEW: 104562
When the Workspace is shutting down the compositor is torn down
before Clients and Unmanaged are released. This means that there
is no need to create the Deleted windows.
Furthermore creating the Deleted manipulates the stacking_order
while Workspace dtor loops over this list to release all clients.
This may cause crashes.
BUG: 282933
FIXED-IN: 4.9.0
REVIEW: 104690
Workspace::addDeleted swaps the Client with the Deleted in the
stacking order. For Unmanaged windows the Deleted is appended
to the stacking order which is the same layer.
When the deleted is closed the window is removed from the stacking
order.
The result is that a deleted window is no longer raised above all
other clients.
REVIEW: 104519
BUG: 158262
FIXED-IN: 4.9.0
The common usage of stacking order is to loop through
the list and find a specific Client. All these usages
still need to find a Client. For that the loops are
adjusted to first cast the Toplevel into a Client and
continue if the current item is no Client.
At the moment all entries in the stacking order should
still be Clients as the Deleted are not yet added.
