The idea is to extend the wrapper to have it wrapping even more
functions provided by Workspace. Of course it would be possible to
just add the properties to Workspace itself and export this. But I
think complete Workspace is just too powerful to fully expose to
scripts. So a small wrapper around the parts which are usefull for
scripts might make more sense.
This breaks now also the API for Workspace and again it is already
more powerful with less code than before.
Unlike stated at several places in the code it is not difficult to
setup the connections to all Clients.
It would have been nice if the failed attempts to connect the Clients
would not have made it into the code as emitted signals which are
nowhere used. Not to mention that like in all places the signals to
inform that a state changed were emitted before the state changed was
performed.
For this properties are defined in ClientGroup and several methods
are changed to be slots (to be invokable from scripts). On Client
the clientGroup is exported as a property.
The existing wrapper around ClientGroup is dropped as it is no
longer needed. Interestingly it was wrong anyway as it allowed to
construct a new ClientGroup, which has to be done internally.
At the same time the meta declarations get cleaned up a little bit.
Whatever it was, we cannot need a "Lazy Logic (TM)" which is not
documented. And even if it were useful, KWin is not the right place
to develop language extensions to ECMAScript.
Each KWin Script is also exported as a D-Bus object and can be
stopped (destroyed) and started through D-Bus. Output and errors
are emitted as D-Bus signals. That allows external applications
(e.g. Plasma desktop scripting console) to load a script and print
out the output.
The general interface is exported as /Scripting and allows to load
a new script by file. The script is not directly executed but only
loaded. To execute it the run method on the script object has to be
invoked.
Dropping the wrapper around Client and just exporting the Client's
properties. This breaks all existing scripts as it's now e.g.:
client.caption
instead of
client.caption()
But the first one is the more natural one for JavaScript and also
for everyone writing QML as well.
Setters and signals are mostly still missing in client. Other parts
like ClientGroup must be converted to properties, too.
It is possible that adding this build option broke the Scripting
component. This is something that should not happen. Unfortunately
by just ifdefing everything scripting related with scripting enabled
we have build errors. These are caused by the fact that the scripting
code includes e.g. client.h through "./../client.h". At one offending
place I changed that to "client.h", but there is also a client.h in
the scripting directory.
The includes and naming of the scripting files clearly have to be fixed!
workspace.clientSetKeepAbove
client.onSetKeepAbove
Documentation updated. Please refer to kwsapi.html for more details.
svn path=/trunk/KDE/kdebase/workspace/; revision=1191158
client.keepAbove
client.keepBelow
client.setKeepAbove
client.setKeepBelow
For more information on the abovementioned methods, please refer to
scripting/apidocs.xml.
These were added in a response to a feature suggestion from Eike Hein.
Thanks a lot Eike :)
svn path=/trunk/KDE/kdebase/workspace/; revision=1180319
also a small conversion program (it's not small and it's horribly ugly,
but it works under 5ms :) ).
svn path=/trunk/KDE/kdebase/workspace/; revision=1180045
A non-void function, Chelate::equivGen was reaching the end of function
without a return value, which could cause a segmentation fault. FIXED.
svn path=/trunk/KDE/kdebase/workspace/; revision=1177875
Every disorder causes every duration, which ensures the one that stays.
reality is relative. natural is disorder.
[R]obinhood[P]andey
Merging scripting from
^/branches/work/kwin_scripting TO
^/trunk
svn path=/trunk/KDE/kdebase/workspace/; revision=1177865
