I've started work on a rewrite of sorts for the dbus plugin that changes how it listens/responds to messages to make it possible to generate introspection data. The main changes are registering every plugin, screen, option, etc with dbus_connection_register_object_path and using libxml2 to generate the introspection data. This more or less works I just need to hook up the rest of the methods and signals that the old plugin had and register/unregister plugins on load/unload. However, I have run into some problems while doing this due to the design of the current dbus interface. Methods like get, set, and getMetadata take/return different types depending on the situation and getMetadata has a variable number of return values. Right now I'm fudging this by lying and having the generated XML say all the different types are strings and by adding in worthless precision of 1 to int metadata to make sure it's the same length as floats. The real solution is to change the API to make it introspection-friendly. Rather than make these changes and submit them I thought it was be a good idea to ask what people thought a good solution would be. The API would ideally have every method take/return the same number and type of arguments no matter what. Any thoughts? -- Travis Watkins http://www.realistanew.com
On Mon, 2007-02-26 at 14:36 -0600, Travis Watkins wrote:> I've started work on a rewrite of sorts for the dbus plugin that > changes how it listens/responds to messages to make it possible to > generate introspection data. The main changes are registering every > plugin, screen, option, etc with dbus_connection_register_object_path > and using libxml2 to generate the introspection data. This more or > less works I just need to hook up the rest of the methods and signals > that the old plugin had and register/unregister plugins on > load/unload.Awesome, I've been hoping that someone would interested in doing this.> > However, I have run into some problems while doing this due to the > design of the current dbus interface. Methods like get, set, and > getMetadata take/return different types depending on the situation and > getMetadata has a variable number of return values. Right now I'm > fudging this by lying and having the generated XML say all the > different types are strings and by adding in worthless precision of 1 > to int metadata to make sure it's the same length as floats. > > The real solution is to change the API to make it > introspection-friendly. Rather than make these changes and submit them > I thought it was be a good idea to ask what people thought a good > solution would be. The API would ideally have every method take/return > the same number and type of arguments no matter what.I'm all for changing the API. If you like to get your current changes in right now we should do that, though. - David
Travis Watkins wrote:> The real solution is to change the API to make it > introspection-friendly. Rather than make these changes and submit them > I thought it was be a good idea to ask what people thought a good > solution would be. The API would ideally have every method take/return > the same number and type of arguments no matter what. > > Any thoughts? >I thought that we were ok for most options because each method is attached to a different object. You should be able to read each option to tell what datatype it is when generating the XML, or am I misunderstanding it? If we change some methods so that they return either arrays or dictionaries then it should make it easier to handle. getMetadata should probably return a dictionary with the restrictions being an array. The real problem is actions (ie activate/terminate) because they can take a variable number of arguments so would need to register somehow.
On 3/18/07, Mike Dransfield <mike@blueroot.co.uk> wrote:> Hi, > > I am just reviewing these patches now and I am getting a > lot of warnings from dbus when I start compiz. > > A handler is already registered for the path starting with path[0] = "org" > > Do you know anything about these messages? > > I have commit access and am ready to commit them but I am not > sure about this error. > >It's harmless. It's just because I register _all_ the plugins when the dbus plugin loads then also register and unregister as you add/remove plugins. So if dbus isn't last you'll get these messages. They don't hurt at all. -- Travis Watkins http://www.realistanew.com
On 3/27/07, David Reveman <davidr@novell.com> wrote:> I told Mike Dransfield to have a look at your patches and include them > if they're OK. Let me know if you need feedback from me. >I keep updating and expecting them to be there. :) Mike didn't seem to have any problems with them other than the harmless warnings from dbus. Mike, is there any reason these patches can't go in? -- Travis Watkins http://www.realistanew.com
On 4/1/07, Mike Dransfield <mike@blueroot.co.uk> wrote:> Hi, > > I am just going through all of these patches and committing them > I am applying them one by one and checking at each point.Awesome.> > I applied 0004 and now none of the other dbus functions > are working. > > I have a plan to make it so that we do not get the re-registration > errors, but I wanted to check all your stuff in first. > > Did you check all the standard stuff with your fully patched > version? This is the command I am using and the error. I > haven't had chance to see whats happening so I thought Id > check with you first. > > dbus-send --print-reply --type=method_call --dest=org.freedesktop.compiz > /org/freedesktop/compiz/core/allscreens/command0 org.freedesktop.compiz.get > > Error org.freedesktop.DBus.Error.UnknownMethod: Method "get" with > signature "" on interface "org.freedesktop.compiz" doesn't existYeah, I prepared them wrong. 0004 and 0005 should have been the other way around. Once you apply 0005 it should work again.> > Regards > Mike >-- Travis Watkins http://www.realistanew.com
On 4/1/07, Mike Dransfield <mike@blueroot.co.uk> wrote:> My plan is to push these changes out and then quickly work > another patch to make it all work properly again. > > Are you OK with this? > >Sounds good, I'll be glad to finally get it committed. :) -- Travis Watkins http://www.realistanew.com