David, is there any chance that the gconf (or dbus) changes will be introduced into the git? because i would really like to get my configurator released, and i can't do it until the option type is available. I have separated all the gconf code in the program into separate wrapper functions so when the dbus changes get into  the head then I should be easily be able to switch the backend to use dbus instead. I think tho there is one option missing with dbus, is there anyway to get a list of plugins available? Thanks, Ben <div>On 11/15/06, Ben Reeves <<a href="mailto:zootreeves@gmail.com">zootreeves@gmail.com </a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">David, is there any chance that the gconf (or dbus) changes will be introduced into the git? because i would really like to get my configurator released, and i can't do it until the option type is available. I have separated all the gconf code in the program into separate wrapper functions so when the dbus changes get into  the head then I should be easily be able to switch the backend to use dbus instead. I think tho there is one option missing with dbus, is there anyway to get a list of plugins available? Thanks, Ben<div> <div>On 11/14/06, David Reveman <<a href="mailto:davidr@novell.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> davidr@novell.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Mon, 2006-11-13 at 05:57 +0000, Mike Dransfield wrote: > Ben Reeves wrote: > > I am writing a configuration front end for the compiz gconf plugin at > > the moment, but it's proving harder than it should be because gconf > > does not record what type of compiz option the key is. For example, > > say i want a color picker for each color option the only way I can > > tell with gconf if it is color  is if it has a # at the beginning, but > > there could be string option which also have a # at the beginning so > > is not reliable. > > > > My proposal is that the short_description of each gconf key should > > contain the option type > > I think the solution for this is to wait until the dbus bindings > support getting information about settings.  I have been working > on this and have a rough solution which I have attached. > > Putting the type into the option description, or a seperate file seems > like it would cause a lot of problems.  The short description is translated > so that would cause bugs, it is also not straight forward for developers. > > The dbus patches are roughly my idea for how information about > options can be got via dbus.  I wrote them so there is one getMetadata > function which returns all the information about the option.  Your > application should cache this information as often as possible. > > I think that the method should return a dictionary rather multiple > return values.  I couldn't find how to create a dictionary so I stopped. > If anyone knows how to do this (or even if I can just return multiple > return values) I would like to know. Great, I've been hoping that someone would implement functionality for retrieving all the option meta data through the dbus plugin. Let me know when this is ready to go into head and I'll have a look at it. -David </blockquote></div> </div>-- Thank you Ben Reeves </blockquote></div> -- Thank you Ben Reeves