Client::manage calls setupCompositing on the not
yet fully managed client before it wants to create
the window decoration. This means the decoration is
created twice and maybe even if not needed (noBorder
not yet set).
If the Client is not yet managed setupCompositing
will not update the decoration - it will be handled
by manage later on.
Furthermore if compositing is not active, setup
compositing does not have to perform any action.
REVIEW: 104758
By moving the query for effects into an own thread the
startup does not have to wait till all effects are loaded.
The thread moves the loading of the effects after the
Window Manager and Compositor has been fully initialized.
This is possible as EffectsHandler is fully functional even
without any effects.
The compositor ensures that at least one frame is rendered
before the started thread returns which makes the complete
startup more responsive.
REVIEW: 104583
The I/O intensive reading of the complete KWin Script
file into a QByteArray is moved into a thread.
Evaluating and setting up the script engine is still
performed in the main thread.
REVIEW: 104782
Searching for the scripts to load is performed in an own
thread including unloading of already loaded scripts which
no longer should be loaded.
To ensure that two threads are not trying to load/unload
at the same time a mutex is added to protect the list of
loaded scripts.
REVIEW: 104768
Instead of getting the information from CompositingPrefs
the running KWin instance is queried through D-Bus.
In general the running KWin should have more information
about whether Compositing will work or not.
This means the kcm no longer has to link OpenGL.
REVIEW: 104753
Detecting CompositingPrefs invokes an external program. Waiting
for this can be moved in a second thread.
Due to the introduction of the thread the initialization order
of KWin is changed: the WindowManager is initialized before the
Compositor. Interestingly this makes KWin felt more responsive
as the screen is not frozen for several seconds.
REVIEW: 104579
Whether creating the OpenGL context succeeds or not
had no influence in any decisions on the used settings
for OpenGL based compositing.
The only valid information CompositingPrefs still detects
is whether direct rendering should be used which is
performed out of process and does not require a context.
So overall the context creation is not needed and can
be removed.
REVIEW: 104778
This means the GLPlatform is filled with values from the
context actually used for Compositing and if XRender
compositing is used no OpenGL information is logged.
There is no need to have it driver specific any more.
All drivers seem to support it (only Intel had been
opt-ed out without any apparent reason shown in commit log).
This was the last driver specific setting which means that
the method applyDriverSpecificSettings() got dropped from
CompositingPrefs.
Strict binding follows the driver (GLPlattform) unless
the user has a config value specified in the kwinrc.
For this a new property is added to Options to indicate
whether strict binding is user defined or follows the
driver. In case of driver the strict binding option is
set when OpenGL compositor starts up.
Toplevel::setupCompositing returns a boolean value and returns
false in the cases where it has not setup compositing.
This is used by the specialization on Client to not perform the
Client specific setup if Toplevel has not setup.
REVIEW: 104767
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
CompositingPrefs have only be used to get the default
value when reading whether the Compositing Enabled
config option.
But CompositingPrefs always returns true which makes
it useless to create an OpenGL context for this.
REVIEW: 104752
The change to have stacking order containing
Toplevel inestead of Clients (431aad6d6994695e72697fcc3299ec2cb6f0684e)
introduced possible crashers as recognized in:
http://git.reviewboard.kde.org/r/104519/#review12714
This change fixes these issues by adding missing
null pointer checks after casting to Client.
BUG: 298669
FIXED-IN: 4.9.0
REVIEW: 104714
This enables the script wrapper objects to automatically create new
dynamic properties for Client objects so that scripts can register custom
properties.
REVIEW: 104697
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
If workspace is exported as a context property there seem to be
issues with the signals which are not bound to a property of
WorkspaceWrapper.
This problems seems to be fixable by exporting the workspace
property as a global property on the script engine.
As a side-effect this also resolves the issue with the clientList,
so we can drop the hack again.
REVIEW: 104682
TabGroup is not (and should not be) a QObject which
makes it rather useless in scripting. In order to use
window tabs in KWin scripts the methods to interact
with tabs from Client should be used.
REVIEW: 104685
Thomas Lübking