scripting plugin discussion

[RYX]

Maybe some of you know the scripting-plugin discussion at the beryl-forum (http://forum.beryl-project.org/topic-3354-scripting-plugin). Because my first approach to design and create a scripting-plugin API didn't raise too much interest among the more eye-candy-oriented beryl-users, I want to start another approach here. I know that at least mikedee also has interest in this and - since compiz aims at productivity and usability - I think this is the right place to continue the discussion. I had to pause the development because the spidermonkey-development package in edgy is broken, but I think I will include the engine as source and let it compile with the plugin.

I will have to remove some beryl-only code before I can upload the initial testing-version somewhere, but I'd like to hear some comments and opinions on having a scripting-plugin in general ...

[To describe my definition of a scripting-plugin: A simplification of the compiz-internals to allow simple window-scripting effects and access to options and other plugins (and maybe basic drawing) - no "language bindings" for language XYZ (I only say that because that's two different pair of shoes and shouldn't be mixed).]

:)

[mikedee]

Here are my quick notes on scripting. As you may have noticed, I have been doing a lot of patches for dbus and some other plumming that is needed internally before things can be scripted easilly.

Most of the internal work is done (or David has on his immediate todo). So all that is needed is to work out a dbus api. There is already access to the options.

Here is what I am planning at the moment.

Once David has committed the patches that send the minimize, close, create window events to the plugins, I want to be able to relay those as signals via dbus. I am then going to add a function to the dbus plugin where an application can register an interest in these signals. Once these are done I will probably add extra things like action initiate/terminate etc.

I think that in itself should cover a lot of requirements for scripters. The only real problem is the visual side of things. The annotate plugin now supports the ability for external apps to render simple shapes and text to the screen directly. Hopefully other plugins can be written can be used for things that require the speed of C.

Your script host could be very very useful if it had the ability to easilly render svg and support javascript like events. You would then only have to add dbus support and everything inside compiz will be available.

Please let me know if there are any other features or information that you would like to get out of compiz, I can probably easilly add it. OpenGL is really out of the question I think :)

[mikedee]

Here is my idea of how all the extra bling features can possibly be incorporated.

You could use dbus and javascript to easilly write a script binding which uses dbus in the background and then creates a CompizDrawing javascript object which could then be used via an easy API, in the future if a different plugin becomes available which does drawing, you could switch to that and the user would not be aware.

If plugins could be written which provide very basic functionality (like miniwin) which can be controlled by dbus, then this functionality will be available at full speed to the script because the hard work can be done inside the plugin.

On another point which I think you are interested in, I think it is possible to add runtime keyboard shortcuts and then trigger then through dbus back to the originating script. This would mean that you could write a script which displays an exact copy of MacSlow's clock whenever you press a key (this be a first milestone to prove the concept). It would actually offer more functionality since it could show like the widget plugin used to do.

Overall I think there should be a scripting plugin which would be generic for all scripting languages, the options could specify how to launch each type of script. This plugin could also offer a few functions which are not really necessary for anything other than scripting use.

[RYX]

That are very good ideas. The plugin-"libraries" (so plugins which hold functionality that is only/partly used from the outside through dbus and/or scripting-bindings) were on my list since you proposed them earlier (or was that someone else? I don't know).

Meanwhile I am really hating spidermonkey (well - not really, but a little), so I more and more like your approach of realizing scripting-functionality through a dbus-"host"-plugin ... we should keep an eye on the upcoming core-changes which will be useful for that purpose (as far as I understood).

I will have a look at the dbus-plugin when I find the time, maybe I can help in improving the event-system ... (But I am still unsure if things like cairo-clock & co shouldn't be better placed inside separate applications. Compiz shouldn't become too overloaded with plugins that could easily be their own apps ... and if it is possible, it will happen (you know murphy's law?) ...)

:)

[mikedee]

I will have a look at the dbus-plugin when I find the time, maybe I can help in improving the event-system ... (But I am still unsure if things like cairo-clock & co shouldn't be better placed inside separate applications. Compiz shouldn't become too overloaded with plugins that could easily be their own apps ... and if it is possible, it will happen (you know murphy's law?) ...)

I agree totally, the plugin code and scripting should be kept as small as possible. My example of cairo clock was as a seperate application. It would be running in a small runtime (either js, python, ruby, bash perl etc), but it would do its drawing by using dbus methods rather than native methods. These dbus methods could easilly be abstracted inside the runtime so that the fact it is operating over dbus is invisible to the script writer.

I think my script loader may have confused you, this should be extremely small and literally just launch the script via the shell, once the script is launched and running in its own process, it can communicate with the dbus plugin to get access to the other plugins internal functions. This way the coupling can be loose so that scripts will not have to be rewritten on each compiz change.

[mikedee]

I have put an example here of using the dbus interface to compiz to do cairo rendering direct to the screen. I have most of the important drawing functions written and I exposed them to dbus.

http://forum.go-compiz.org/viewtopic.php?t=104

This script puts the cairo clock onto the screen, I had to use a double buffer so that the clock didnt flicker.

There are a few limitations in dbus at the moment which might be tricky to get around, the main one is that dbus actions do not return anything and the core hasnt been written so that it could (very easilly). This functionality would be useful because we would be able to call dbus methods which return information about things like current viewport. In this example I would be able to load the svg and then return a reference to it which could be used next time. The clock makes the screen jumpy every time it updates because it is reloading each svg every time.

Have a look at the python code (its less than 150 lines) and let me know what you think. The commands I am using are the raw dbus commands so they are a bit wordy. These functions could be abstracted out easilly, but we should work out some sort of api map first. The problem is we are slightly restricted by the dbus bindings so the high level abstraction will be influenced by it.

[RYX]

Great job! I wasn't able to try it yet (I don't have compiz-get installed) but I know how much lines of code cairo-clock is made of - and your 100-lines version is much easier on the eyes ... (though python looks still "uncommon" to me). I will give it a try later today (my work is heavily occupying me another week) ...

Keep on rockin' ... :D

:)

[mikedee]

Here is my first draft for a scripting plugin, all it does is load the scripts specified in the config. This should make it much easier to distribute scripts.

I have modified dbus so that it forwards notifications as messages. I have added the basic notifications that compiz has now, but hopefully there will be more of them.

There is also a modified annotate so that cairo-clock can work.

To install this just unpack and cd to the directory and type ./install.sh, this should install all the modified plugins and the scripts, then go to gconf-editor and add the scripts you want to run to the /apps/compiz/plugins/scripting/allscreens/options/scripts key. Enter just the name of the script, the plugin will only look in ~/.compiz/scripts/

The scripts are just cairo-clock.py and signal.listen.py. cairo-clock.py puts the cairo clock on top of the screen and signal-listen.py is just an example for listening for compiz events.

http://www.anykeysoftware.co.uk/compiz/plugins/scripting-0.1.tar.bz2