Scripting plugin release

[mikedee]

I thought I would start an official thread for the scripting plugin and general scripting of compiz (the hard work is done by the dbus plugin).

I have added a lot of features to ther first release and fixed a few bugs (as well as creating a few new ones :))

Here is a quick overview of the api so far, dbus is an oo style binding so there are objects with sub objects and methods on those objects. The object is represented by an object path like this

/org/freedesktop/compiz/rotate/screen0/timestep

This example represents an option object.

Here is the breakdown of each object and the methods available.

Compiz Object

Path
/org/freedesktop/compiz

Methods

getDisplayData () - returns a dictionary with all the relavent information about the display (there is not a lot that seems useful).
getScreenData (int screen_id) - returns a dictionary with the screen information.
getWindowData (int window_id) - supply with a window id and it will return a dictionary with all the relavent data.
getWindowList (int screen_id) - returns a list of all the windows for a given screen id. This is the same as the windows that appear in the switcher so there shouldnt be any non user windows there.

Screen/Display Object

This represents a collection of screen or display options for a particular plugin.

Path
/org/freedesktop/compiz/plugin/[screen0|allscreens]

Methods

getOptions () - will return an array of all the options for that screen/display.

Option Object

This represents an individual option in gconf. This allows you to set and get values, plus allows you to activate and terminate any action options.

Path
/org/freedesktop/compiz/plugin/[screen0|allscreens]/option_name

Methods

getValue () - Gets the value for the option.
setValue (variant value) - Sets the option value
getMetadata () - Gets the information about the option, description type etc.
get[Int|Float|String]Rest - these methods get the restrictions for int, float and string options.
activate (int root_id) - if the option is an action then you can activate it as if the user pressed the buttons with this method, it normally takes the root_id, but it can also take other parameters, depending on the option. The root_id can be found out by querying the screen object.


In addition to methods on objects, the dbus plugin also sends different signals on certain events. At the moment the list of events is restricted but David will shortly add more. The events that are forwarded as signals are:

windowMoveNotify
windowGrabNotify
windowUngrabNotify
windowResizeNotify
windowStateChangeNotify
xMotionNotify
xCreateNotify
xDestroyNotify
xFocusIn
xFocusOut
xMapNotify
xUnmapNotify

The last x events are provided by the scripting plugin and are a bit of a hack for the moment until things are clearer with events.

There is also a signal sent out for each compizEvent, these will normally be plugin specific information, I have used it to preload the svgs for the clock.


I have updated the cairo-clock.py script so that it now hides if a window covers more that 1/4 of it. You can change the options at the top of the script.

Known issues

The FiniDisplay function doesnt work as I expect and it doesnt kill off the scripts if compiz is reloaded. cairo-clock tends to die as soon as it notices that the bus is unavailable but the other test scripts do not. Watch out for this for the moment.
It isnt possible to add custom key/button bindings, in theory it should be possible but my quick tests didnt work properly so I have removed it for now.


Download

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

To install just unpack and type ./install.sh in the directory, this will compile and install the scripting plugin as well as the dbus and annotate plugins that are needed. Make sure all of these are loaded in compiz and then restart compiz to make sure :)

To run cairo-clock just enter cairo-clock.py in the scripts option and it will be started automatically.[/b]

[iznogood]

I tried it but the dbus plugin segfaults compiz

I use compiz from git so it might need some changes ???

[mikedee]

What were you doing when dbus segfaulted?

Are you able to get a backtrace?

Quick instructions for backtrace

Install gdb

$ gdb compiz
(gdb) run --replace gconf

blah...blah...

Then crash it, swich to another terminal and restart metacity.

Program received SIGSEV blah blah
(gdb) bt

Copy and paste this output

[mikedee]

Its OK, I think I have tracked down the problem, can you try 0.9.1 and see if you have the same problem.

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

[iznogood]

OK i just tried it and it seems fine.

One very minor thing though...
I removed the script(cairo-clock) from the plugin params but it did not stop.
I had to remove the plugin from the active plugins list and then re-enable it.

Also the plugin makes compiz performance suffer a bit. I guess that it is better suited for other jobs than rendering. Maybe its just a python thing???

Besides all that, i must say that i am really impressed.The concept of using dbus for RPC like stuff its great and it will allow people to make great things with compiz without touching the core. Would it be possible for more plugins to be converted to use dbus (like trailfocus) for things that are not process intensive???Maybe we must explore this area and expand scripting-dbus plugin.It will give us a new level of indirection that will make binary linking problems go away and allow people to hack on the core without breaking existing functionality

[mikedee]

I removed the script(cairo-clock) from the plugin params but it did not stop.
I had to remove the plugin from the active plugins list and then re-enable it.

I am just being lazy here, I have to write some code which detects which scripts are running which are no longer in the list, its a bit fiddly so I have put it on the todo list :)

Also the plugin makes compiz performance suffer a bit. I guess that it is better suited for other jobs than rendering. Maybe its just a python thing???

Yes, I am trying to get to the bottom of exactly what causes the slowdown. I _think_ (now) that it is due to the plugin waiting between screen draws whilst it processes dbus messages. There are also a lot of window move notifications sent when the cube is rotating, this is overloading the bus sometimes.

There are a couple of optimizations which I can also add to see if I can improve things. This will be my main focus now because it would be really good to have at least 1 second refreshes without too much slowdown.

Even if it cannot be made super quick, it can always be used as a testing ground for new plugins. Hopefully people will be able to mock up plugin ideas with a script and if it is popular or needs that bit extra performance it can be converted to a proper plugin (the cairo clock could easilly be converted to run full speed as a native plugin, but thats not really the point of the example).

[iznogood]

are your changes in dbus-annotation going to be merged upstream or i must sync manually ???
Any info from davidr

[mikedee]

I have sent some of the dbus changes, I will send the annotate changes once I have added rotating support to svg and added image support. He has agreed in principle some of the dbus changes.

Most of the annotate stuff has been added already, the only extra is svg support which should be accepted because it can be used as a custom brush by non dbus users.

I hope everything can be accepted into the plugins upstream, but if there is anything that David does not want to accept then I can easilly implement those features in the scripting plugin. I would rather keep the scripting plugin as a small script launcher and manager type plugin, but it doesn't matter if I bring in scripting sprcific functions.

I think David is a bit busy at the moment with patches so I will hold them here for the meantime whilst I work on them. Once we have our own git it will be easier to keep these extra plugins in sync.

[Amaranth]

Using dbus-viewer to try to browse around org.freedesktop.compiz makes compiz crash. Also, it seems any error in the scripts will bring down compiz as well.

[mikedee]

Thanks for the feedback, the current version of dbus does not include the dbus-viewer tool so I assume it has been removed recently. The dbus plugin does not support introspection at the moment so it is unlikely that you would see anything useful anyway.

Could you please post an example of a script which crashes it, I am able to crash the script (ie. get python to throw an uncaught exception). But I didnt find anything to reliably crash it. The signal code needs some tightening up but I wanted to add it to show what is capable.

[Amaranth]

dbus-viewer is one of the qt4 example applications.

cairo-clock.py throws an exception about a dbus timeout then compiz starts running in a crash/load loop.

[mikedee]

There is a file in the annotate folder called render examples, can you try running than and see what the output is.

Ill try to get a hold of dbus viewer but like I said, there would be no useful information there anyway, although a crash is interesting.

Your dbus version may be useful too. I am running 1.0.1. I use gentoo and kdbus requires dbus 0.62.

BTW, do these problems happen when you are rotating the cube?, this is a known issue.

[Amaranth]

When I run the examples compiz does it crash, spawn, repeat game. When I tried to run it under gdb X froze. Really weird stuff. Note: This does not happen in beryl (I ported the changes over to test).

[mikedee]

I do not mind you testing this privately, but can you please remove it from the beryl svn repository. It is not licenced under a free licence and you do not have permission to redistribute.

[QuinnStorm]

Quick note, we did not know it was not under a free license as it was not clarified, and released in connection with a project released under MIT/GPL.

Now that we know this, we have removed it, though I also ask, what license is it released under? Could you clarify so that this does not happen to others?

[gnumdk]

I know you don't like beryl project mikedee... Are you sure this plugin is non free software?

For now, i remove it from my computer, i dislike non free software...

[Guest]

Mikedee if you really don't want the beryl project to use your code, release it under the MPL, still a free license but incompatible with the GPL .(compiz-settings, is under that, but i think i might change that in the future

[mikedee]

gnumdk - to you it is free software :)

I will have to choose an appropriate licence for it though, I will need to have a look at them all and see which one is best for me. It will be a free licence, but it will not allow forking thats all.

So for the meantime, it is realeased under a free licence but you are not allowed to distribute it unless you have permission.

[Guest]

It will be a free licence, but it will not allow forking thats all.
Isn't the very definition of free software that it can be forked/re-distributed?

[mikedee]

It will be a free licence, but it will not allow forking thats all.
Isn't the very definition of free software that it can be forked/re-distributed?

I thought more that people are free to read, learn from, modify, improve the code. That is what they gain from it. Redistribution is fine.

As far as I can see the GPL was specifically written to stop forking which destroyed unix in the 80's. Microsoft walked all over the unicies because they all had slightly incompatable versions and customers eventually chose to go with Microsoft. The same thing is happening with compiz/beryl.

The GPL has been strong enough to prevent forking for a while. The problem is that certain people and companies have found that you can get around the no-fork nature of the GPL.

These people release their source in compliance but they make it so that it is impossible to pull one patch from the other, so the software forks (and is effectivly stolen). Apple tried it with the KHTML code and I do not want the same happening to me. At the end of the day, I spent the time thinking up, building and debugging. I should have the right to distribute freely without it being stolen.

So forking is bad and we should aim to reduce it.

[Amaranth]

Another bug, this one with your dbus changes.
annotate: [u'initiate', u'draw', u'transform', u'switch_context', u'erase', u'clear', u'fill_color', u'stroke_color', u'line_width', u'stroke_width', u'svg_file', u'tool', u'preload']
dbus: [u'initiate', u'draw', u'transform', u'switch_context', u'erase', u'clear', u'fill_color', u'stroke_color', u'line_width', u'stroke_width', u'svg_file', u'tool', u'preload']

As you can see, it's giving dbus all of annotate's options. This happens with every plugin you call getOptions on in the same script. Eventually you end up with one plugin having hundreds of options.

[Amaranth]

Another test shows that this only happens for "allscreens" options, not "screen0" options. Also, your first post says "getMetaData" but it's actually defined as "getMetadata".

[RYX]

Mikedee, I think you, as the one who is porting any plugin from beryl ten minutes after its release, should not start with such an egotrip-behavior. What if cornelius starts releasing his animation-plugin under a beryl-only license and then all other beryl-devs follow? I think there is absolutely no reason to release your plugin under such a special license and you should stop your personal war against beryl before you cause bad results for all compiz-users. Don't let the community suffer from your anti-beryl attitude.

[mikedee]

I dont think I am on an ego trip. I wrote the plugins and I can decide how to licence them. Zootreeves licenced his configuration tool as MPL, why cant I? BTW, zootreeves, you will need to release this as GPL if you link it to libberylsettings.

Beryl developers cannot release their plugins under a beryl-only licence, they must use GPL or nothing.

[RYX]

Of course - you are free to choose any license for your work. But one could get the impression you are just choosing another license to stop the beryl-devs from porting your plugin to beryl while you are the one porting all beryl-plugins to compiz. And - honestly - how ironic is that? (I only ask because you always mention the irony in all beryl-devs' actions)

I don't want to criticize you in your license-decision - do whatever you please with your work. But I think you shouldn't point with the finger at others while you aren't doing better at all.

[Guest]

I'm not saying this is the right thing to do, but It's kind of the same thing that beryl has done with licensing their code under the GPL. They can take our core code and we can't take theirs, but we can take their plugins and they can't have ours. seems fair to me..

Hadn't thought about the libberylsettings issue, I guess their goes beryl support..

[gnumdk]

you are just choosing another license to stop the beryl-devs from porting your plugin to beryl

In fact, if you can't fork a software, this software is not free software. All free licences permit fork... MPL permit fork (iceweasel).

There is no obligation for beryl dev to release their plugins under GPL! They can write a plugin with a BSD licence, it will be legal...

Look at Kde, kicker is a BSD licenced application linked to a GPL one(Qt).

[mikedee]

I am not looking to prevent a fork necessarilly. I would be happy with the MPL, since it just prevents the licence being changed when it is redistributed (which seems fair enough to me).

I think Ill probably go for the MPL since its a nice licence. I need to read through it again though just to make sure its what I want.

[mikedee]

There is no obligation for beryl dev to release their plugins under GPL! They can write a plugin with a BSD licence, it will be legal...

Yes, but Quinn doesnt like anything other than GPL, if they changed their plugin licence they would be kicked out of beryl.

[cyberorg]

From what I read here it seems like compiz community is nothing but anti GPL, and present things that M$ would want, like GPL is evil.

Please try an make it more friendly one, instead of being generally hostile as it currently seems.

Not a very nice place to be.

(I hope all of the 200 members don't share this anti GPL stand, I am part of this community, at least I don't)

[mikedee]

Anti GPL?

Other than me, I havent heard anyone say even half a word 'against' the GPL. I believe that licences are just legal documents to protect my work. I do not like or dislike them, they are just legal documents. I do however understand that each licence should be used where it is necessary, I dont just blanket wash everything with the GPL to win friends.

Please stop trying to spread FUD. I LIKE the GPL - as far as I can tell everyone else in the compiz community is 100% pro GPL and free software.

[Amaranth]

BTW, zootreeves, you will need to release this as GPL if you link it to libberylsettings.

Not so fast there, it's not quite that simple. If it's got multiple independent backends you can argue that as it does not need libberylsettings to work it is not a derivative work. Either way, you can just use the dbus interface to work with beryl and compiz and skip the whole licensing bullshit-fest.

[RAOF]

BTW, zootreeves, you will need to release this as GPL if you link it to libberylsettings.

Not so fast there, it's not quite that simple. If it's got multiple independent backends you can argue that as it does not need libberylsettings to work it is not a derivative work.
...
As long as it doesn't statically link in libberylsettings, or get compiled on days which are divisible by consecutive primes. :)

[lupine]

I don't know where "The GPL has been strong enough to prevent forking for a while" and "the GPL was written to prevent forking" comes from... the GPL is fork-neutral. One example would be emacs and xemacs ;). rms hates xemacs with an unholy passion, but it exists - and people use it - every day, anyway - and with his (ideological, if not personal ;) ) blessings.

The GPL was written to protect the freedom of software - as rms put it. "software wants to be free"... the GPL does that by allowing an author to say "this is my software, and you can do pretty much anything you like with it, as long as you extend to same courtesy to other users." That's it, in a very simple nutshell (and not quite factually accurate, I know, but this isn't the main focus of what I'm posting).

"All the unices" were non-GPL and proprietary... so of course they had incompatibilities. They weren't forks of each other - they were implementations of a similar ideal. For an analogy, look at the differences there were in the early days of MS Office and Lotus Notes. It's the same sort of thing.

From that, it's obvious that comparing the interaction between two open-source projects to the interaction between two closed-source projects is nothing short of naive. Forking is half the power of Free/open source; merging (and more general collaboration) is the other half. And of course, half the power of collaboration comes from forked projects talking to each other...

Under GPL, where two different software projects have similar goals and outlook, they usually end up merging. The inverse, of course, is that if some people want to take a particular piece of software in a different direction to the original developers... they can. If that code remains apart from the original source... you have a fork.

As to beryl being GPL-only... I wouldn't be contributing (well, perhaps that's too strong a word!) to it if it wasn't ;)... I'm something of an FSF fanboi. Given that compiz was released under a license that explicitly /allows/ clobbering of this sort, it's a bit unfair to argue that beryl is stealing code. Likewise, it's a bit silly to argue that you shouldn't be porting beryl plugins to work with compiz. We all chose our licenses in full knowledge of what they permitted - at least, I hope we all did! - so let's try to be (wo)man enough to be graceful when people do things that we//they have explicitly stated that they/we are allowed to do.

And yes - less of the FUD would be excellent.

xF,

...Nick

[mikedee]

Just to clarify, the part of the GPL which activly prevents forking is the part about contributing back changes. You cannot fork if you give all the changes back, likewise you cannot maintain a fork if the original developers are allowed to take back your great new code. As you said a fork is a vital safety valve. I think that the valve was released way too early in this particular case which has led to the disagreements and people feeling that forks were made without good reason.

This is why I am justified in porting the plugins because 1. A lot of the plugins were written for compiz not beryl. 2. I am actively preventing the fork and therefore keeping Linux from becoming more fragmented, the point of the unix forking wasnt to show that free software is good, it was to show that forking is bad generally because it leads to wasted effort incompatabilities and general user confusion. I ported the plugins to really just prove the point that there is no technical reason for the beryl fork. If you remember the original reasons were technical - xinerama, csm/gconf etc - as time went on it has become more a free software lovers vs free software haters debate (which is another false dichotomy that beryl devs are now trying to spread).

What the beryl devs did was totally legal, I just do not think it was moral.

Having said this, the whole debate is totally off topic, this particular plugin is released under the MPL which is also a free licence. The only restriction to taking it into beryl comes from the GPL only stance that they take, it is nothing to do with me.

[lupine]

Oh, no worries - I personally have no issues with beryl plugins being ported to compiz (and vice-versa, of course). As long as nobody is breaching anyone else's licenses, and credit is given where credit is due, I'm sure we can all get along well enough :).

Of course, a plugin originally designed to work in compiz that - with a few tweaks - works in beryl can't be said to be a derived work of beryl (as I understand the legalities, which isn't all that well TBH); so I can't see there being anything that'd prevent a dedicated person (not me - i've got enough to do :p) unoffically porting this plugin to work with beryl... any thoughts or comments on that?

I'm not trying to stir or anything; I'm just genuinely interested in the way you seem to want to approach this issue.

IMO, the only reason needed for a fork on compiz would be the "it's not GPL" bit - but opinions will :roll: differ :roll: on that point, I've no doubt. But at the end of it all, maybe - just maybe - we'll end up with a couple of pretty decent compositing window managers.

Personally I see Compiz eventually getting incorporated into all the big proprietary solutions - like Microvell Winux 2015 ;) - (j/k) - due to it's more permissive licensing and generally more businesslike outlook. On the hobbyist/home user front, I think there's not too much to distinguish them - maybe compiz is a bit more stable (or then again, maybe not :p); maybe beryl has a few more features (again, perhaps not!). Die-hard FSF-loving penguins like myself will, of course, be using beryl with our Free graphics drivers. And there'll be REM's "happy shiny people" playing in the background and we'll all be holding hands...

OK, enough of that :p. "False dicohotomy" is a matter of interpretation, I suppose. And as you pointed out, well off-topic.

xF,

...Nick

[mikedee]

so I can't see there being anything that'd prevent a dedicated person (not me - i've got enough to do :p) unoffically porting this plugin to work with beryl... any thoughts or comments on that?

There is nothing to prevent you or anyone else converting this plugin to beryl or even distributing it. I even provide instructions on how to do that (in reverse anyway).

I'm not trying to stir or anything; I'm just genuinely interested in the way you seem to want to approach this issue.

Which issue? Me licencing my plugin?

IMO, the only reason needed for a fork on compiz would be the "it's not GPL" bit - but opinions will :roll: differ :roll: on that point, I've no doubt. But at the end of it all, maybe - just maybe - we'll end up with a couple of pretty decent compositing window managers.

So if beryl is the GPL version of Compiz, then why is there binary incompatability any why do they refuse to send patches? There is nothing stopping them from taking Compiz, relabelling it beryl and then releasing it under the GPL. The talk at the time was that there were technical reasons and that compiz needed to be rewritten. Now things seem to being diverted into false licencing issues.

Personally I see Compiz eventually getting incorporated into all the big proprietary solutions - like Microvell Winux 2015 ;) - (j/k) - due to it's more permissive licensing and generally more businesslike outlook.

So assuming that is a joke, who are these big proprietary solutions that are likely to incorporate Compiz? There is windows and osx as far as I can see, none of them are at all likely to incorporate Compiz. Even if they did, creating beryl will not stop them, there is nothing radical or exciting in beryl, so as you say there is no difference. Berly takes most of the core code from Compiz these days anyway (check the svn log if you do not believe me).

Also all of this is rather hypocritical since the only goal of beryl at the moment is to be included in Ubuntu, which I hate to break to you is run by a commercial company. They also have a history of making the community work hard and then screwing them over in the end (ref edgy designs).

Iam more than happy to answer any sensible questions you may have, please could you start another thread though :)

[apoclypse]

[/quote]
They also have a history of making the community work hard and then screwing them over in the end (ref edgy designs). [/quote]

Thats harsh. Edgy had far less time to develop than previous ubuntu versions, a lot of things had to be axed because they weren't ready at the time of edgy's release. Thats not to say that a lot of users and developers were let down, but do they honestly think that edgy was ready at release? Edgy is pretty unstable as compared to Dapper, its an okay release that could have been great had they taken the time, or given the developers the time to work on it. Feisty seems like it will have some great things coming out of it. Hopefully, everything will be implemented, but who knows.