If it can't be stored in the schema, what if it was stored in a seperate key. e.g. each key has another key with the same name %key_name%_option_type (or something along those lines).<br><br>e.g.<br>/apps/compiz/general/allscreens/options/close_window_key should also have another key
<br>/apps/compiz/general/allscreens/options/close_window_key_option_type = "CompOptionTypeAction"<br><br><div id="mb_0">/apps/compiz/plugins/cube/screen0/options/skydome_gradient_end_color <br></div>/apps/compiz/plugins/cube/screen0/options/skydome_gradient_end_color_option_type = "CompOptionTypeColor"
<br><br>I would prefer not to use dbus because if anyone turns the plugin off (or it fails) then the user will not be able to change the configuration to change it back. However if dbus is the only option, mike could you possibly give me an example of how I would retrieve the key type using your code. Thanks
<br><br><div><span class="gmail_quote">On 11/13/06, <b class="gmail_sendername">Mike Dransfield</b> <<a href="mailto:mike@blueroot.co.uk">mike@blueroot.co.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ben Reeves wrote:<br>> I am writing a configuration front end for the compiz gconf plugin at<br>> the moment, but it's proving harder than it should be because gconf<br>> does not record what type of compiz option the key is. For example,
<br>> say i want a color picker for each color option the only way I can<br>> tell with gconf if it is color is if it has a # at the beginning, but<br>> there could be string option which also have a # at the beginning so
<br>> is not reliable.<br>><br>> My proposal is that the short_description of each gconf key should<br>> contain the option type<br><br>I think the solution for this is to wait until the dbus bindings<br>support getting information about settings. I have been working
<br>on this and have a rough solution which I have attached.<br><br>Putting the type into the option description, or a seperate file seems<br>like it would cause a lot of problems. The short description is translated<br>
so that would cause bugs, it is also not straight forward for developers.<br><br>The dbus patches are roughly my idea for how information about<br>options can be got via dbus. I wrote them so there is one getMetadata<br>
function which returns all the information about the option. Your<br>application should cache this information as often as possible.<br><br>I think that the method should return a dictionary rather multiple<br>return values. I couldn't find how to create a dictionary so I stopped.
<br>If anyone knows how to do this (or even if I can just return multiple<br>return values) I would like to know.<br><br>Mike<br><br><br></blockquote></div>