config daemon/library for 4.6

[Erik Harrison]

On 9/5/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> 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  *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).

Panel plugins are a special case because the panel guarantees that
their configs don't step on each other or pull old settings. I suppose
the panel could simply provide the XfconfChannel object and pull the
same naming trick it does now with config files.

>
> > 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 hate error handling, it's terrible and it's always ugly, but it
should at least be possible to add in a printf and see what's going
on.  I'm a terrible programmer after all.

If we're going to support diverse backends, then we'll need a way to
pass those up, since backend developers will need to be able to debug
their work, and potentially have obscure or complex error conditions.

> 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
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev
>


-- 
Erik
"If you want to go somewhere, goto is the best way to get there." - Ken Thompson