config daemon/library for 4.6

[Brian J. Tarricone]

Nick Schermer wrote:
> Maybe the xfconf_channel set functions can be written as va_lists. So
> you can write multiple settings (in 1 transaction) using
> 
> gboolean xfconf_channel_set_string(XfconfChannel *channel,
>                                    const gchar *property1,
>                                    const gchar *value1,
>                                    const gchar *property2,
>                                    const gchar *value2,
>                                    NULL);

I'm ok with this for a multi-*set* API...

> For that reason I also prefer the fist way you retreived the variables
> (in combination with va_lists):
> 
> gboolean xfconf_channel_get_string (XfconfChannel *channel,
>                                    const gchar *property1,
>                                    char **value1,
>                                    const gchar *default1,
>                                    const gchar *property2,
>                                    char **value2,
>                                    const gchar *default2,
>                                    NULL);

... but absolutely not.  That's just plain ugly.  Can you describe a 
use-case where you'd want to get several value from a channel, but not 
all values?  Even just requesting 3-5 values one by one sounds 
preferable to me than this.

> Maybe it's also useful to have a function to remove a channel and all
> the properties inside (for example when a plugin is removed from the
> panel, the panel can ask to remove all the plugin settings).
> 
> gboolean xfconf_channel_remove (const gchar *channel_name,
>                                     GError **error);

That sounds reasonable.  Another option would be to just remove the 
channel when all properties are removed, but that's annoying.

But really -- what application *ever* cleans up its settings on 
uninstall?  Plugins never do either.  Is this even necessary?  Yes, the 
store could get cluttered, but unused channels shouldn't impact the 
daemon at all (they won't get loaded if no one asks for them).

> The current api also lacks a bit of error handling, so errors in
> xfconf_channel_remove_property for example
> 
> gboolean xfconf_channel_remove_property(XfconfChannel *channel,
>                                     const gchar *property,
>                                     GError **error);
> 
> Was the property not removed because it does not exist? Or not allowed
> because of kiosk mode? stuff like that

Does it matter?  I left out the error returns for simplicity.  Really, 
how are they useful?

1.  The daemon is unavailable or broken -- so what, what's the app going 
to do with this?  Well, it's going to use it's default value.  Current 
API handles this.

2.  The property is read-only -- this will be handled separately via a 
_is_writeable() API call that I haven't added yet.

3.  The property doesn't exist in the store -- so, it's gone, isn't it? 
  For getters, the app will want to fall back to a default value, which 
the current API handles.

I really don't see any need to report detailed errors to the 
applications.  Please feel free to try to change my mind if you can 
think of reasons.

> Macros to read channel stuff
> XFCONF_CHANNEL_IS_WRITEABLE() could be useful too.

This is coming later, but with actual functions -- this will need 
special support in the daemon and the dbus protocol, and I haven't quite 
hashed it out yet.

> Just my 0.02,

Thanks!

	-brian