[compiz] DBus setting options broken

[David Reveman]

On Wed, 2007-01-03 at 04:05 +0000, Mike Dransfield wrote: 
> >
> > Nevertheless, even though it should work now, I wouldn't necessarily
> > make synchronous method calls if I were you. You don't have to use
> > threads to do asynchronous method calls. Whatever dbus bindings you're
> > using should have a non-blocking way to send messages. I wouldn't want
> > to block for each method call if I were setting a large amount of
> > options.
> >   
> 
> I had a similar problem with my scripting plugin [1]
> I have modified annotate dbus and plugins which take
> a request to load a svg and then return a int handle to
> the svg once it is loaded.
> 
> I was going to use the filename as the identifier for the
> request but maybe it would be better if something could
> be added to dbus to allow for asynchronous methods
> better.  Do you think this would be OK?
> 
> [1] http://forum.go-compiz.org/viewtopic.php?t=138
> 
> The plugin and everything are basically just experiments
> to making a complete dbus interface to compiz (as far as
> possible anyway)

I've look at the thread. Some comments:

getScreenData, getWindowData, getWindowList and such methods will return
a lot of data that is currently available as X properties on client
windows and the root window and part of the EWMH spec. I don't know to
what extents that data is available in existing scripting languages. If
it's already available, then I wouldn't feel good about adding a new
incompatible way to get that data through compiz. However, I can imagine
that having all that data available through dbus would be convenient but
maybe we should provide it as a netwm object (/org/freedesktop/netwm)
instead so that other window managers could provide it too and only put
the compiz specific stuff in the compiz object.

In the description of the "activate" method you mention that it can be
used to activate an action as if the user pressed a button. We want to
be able to use it to activate an action in other ways too, right? As a
button-press, key-press, screen edge-event and as none of these.

Exposing notification functions like windowMoveNotify,
windowResizeNotify and windowGrabNotify makes a lot of sense. They will
likely change a lot soon and new ones will be added but you seem aware
of that.

In general it's all very useful functionality and I definitely want to
see it in the dbus plugin. I think this can land in the dbus plugin soon
if we sort out the netwm thing and the much needed "notify" function
cleanup that I've been planning to do to compiz gets done so that we
don't have to expose X events.

Keep up the good work!

-David