The only task of the PaintRedirector is to redirect the painting of the
window decorations into Pixmaps. So it should actually do this by also
handling the four pixmaps for the decoration. This simplifies the code
as all the logic concerning redirecting the painting is now grouped
together.
Furthermore the PaintRedirector is now a child of the decoration widget,
which means it gets automatically destroyed whenever the decoration is
destroyed - the Client does not have to care about it.
Also the PaintRedirector gets only created if the Compositor is active as
it is not needed in the non-compositing case.
REVIEW: 106620
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.
The method windowType needs actually two implementations:
* one for Clients
* one for Unmanaged
as for Clients also the window rules are checked and hacks are applied
which is both not needed for Unmanaged windows.
To have the Client specific behavior in windowType the function used to
perform two dynamic_casts which made this method one of the most
expensive during compositing, e.g. for ~1000 frames
* called ~43000 times
* ~85000 dynamic casts
* incl. cost of method: 0.24
* self cost of method: 0.05
* incl. cost of the casts: 0.12
After the change to remove the dynamic casts we have for ~1500 frames
in Client::windowType:
* called ~31000 times
* incl. cost of 0.06
* self cost of 0.02
Calls on Unmanaged and Deleted are so low that we do not need to consider
them.
BUG: 306384
FIXED-IN: 4.10
REVIEW: 106349
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 geometry setting needs to happen out of recursion,
has to be smarter for unmaximizing and also no real
place in TabGroup - the client is no longer tabbed thus
it's not the groups task to manage it's geometry.
BUG: 226881
REVIEW: 106182
FIXED-IN: 4.9.1
the geometry setting needs to happen out of recursion,
has to be smarter for unmaximizing and also no real
place in TabGroup - the client is no longer tabbed thus
it's not the groups task to manage it's geometry.
BUG: 226881
REVIEW: 106182
FIXED-IN: 4.9.1
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.
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.
as the flamewar pointed out, resetShowingDesktop invalidly keeps hidden windows
the reason is that there're several updateVisiblity calls (notably one from the compositor)
which break the showingDesktop state as a side effect (before ::manage() does it's thing)
Since they also invalidate the Withdrawn mapping state, that will fail as isManaged() test
(it's also invalidly used by the compositor to set up the decoration, isManaged() used to be
true because of the updateVisibility() call before) since the result is never Withdrawn
CCBUG: 299655
REVIEW: 105303
When trying to launch kickoff (start menu) or the add widgets from
Plasma, they disappeared immediately after appearing, making them
completely unusable.
This regression was traced back to commit
bf0a241c2462072fbc52012784fa51b9b42a1baf.
In Client::setOnActivities, if newActivitiesList was empty, after
joining it and splitting it back, it would contain an empty string, i.e.
it would have a different size than before. This eventually caused the problems.
REVIEW: 105016
Client holds a SharedPointer to the TabBoxClient and only
provides access to a WeakPointer which is passed to TabBox.
ClientModel is adjusted to hold a list of WeakPointers instead
of the direct pointers.
This fixes the following reproducable crash:
1. Configure both primary and secondary TabBox with different
layouts
2. Use primary TabBox
3. Close a window, best the one which used to be active
4. Use secondary TabBox
-> Crash
The reason is that the ClientModel still contains the pointer
to the deleted TabBoxClient in step 3 and while creating the
layout access to the TabBoxClient is needed to get the Client's
icon.
By using the weak pointer it can be ensured that we don't try
to dereference the deleted pointer and prevent the crash.
CCBUG: 290482
CCBUG: 285747
CCBUG: 237345
REVIEW: 105000
- adds the kcm rule option to set the activity - one or all option like
for virtual desktops
- makes the windows obey the rule
- makes the rule enforced even when the user tries to change the
window's activity via the alt+f3 menu
REVIEW:104972
cppcheck complained about that piece of code and it was not
really good. A TabBoxClient belongs to exactly one Client which
means the setter should for Client should not be there in the
first place and was only used during construction.
REVIEW: 104909
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
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.
Allows to block compositing on Client's from scripts.
Usecase: window rule cannot properly identify buggy
clients and scripting allows to just act on fullscreen
windows.
BUG: 297146
FIXED-IN: 4.9.0
REVIEW: 104448
