config daemon/library for 4.6
Brian J. Tarricone
bjt23 at cornell.edu
Wed Sep 5 23:22:44 CEST 2007
Nick Schermer wrote:
>>> Exactly that is what I had in mind. Just provide a unique XfconfChannel
>>> to each plugin and that's it. It doesn't sound like a bad idea to
>>> cleanup old settings of plugins when they are removed from the panel.
>>> And after all, such an xfconf_channel_remove() function wouldn't cost
>>> much time to be written.
> Remember that plugin can have a different read and write location.
What do you mean? A plugin would read settings from one location and
write to another? Why?
> And plugin settings are already removed when you remove the plugin
> from the panel (the unique id will never be generated again),
> therefore I'd like to have a xfconf side way of removing the data. It
> doesn't matter if it's *fast* or not.
Er, no they aren't, unless you've changed this in SVN. I have loads of
stale config files in ~/.config/xfce4/panel/ from plugins I've removed.
>> Ooh, I like that. To avoid complicating the dbus interface,
>> _channel_remove() may be client-side: it just does GetAll() and then
>> Remove() on each property. The daemon could have a policy that it
>> removes a channel if it has no properties left. This isn't optimal
>> performance-wise (a round-trip per property), but it's not a common
>> operation. Should I care about optimising this, or just add a
>> RemoveChannel() method to the dbus API?
> I've vote for _property_remove in dbus and _channel_remove clientside
> if that also cleans the channel_name (with a file backend: not only
> emty the file, but also remove it).
>> Does it matter? I left out the error returns for simplicity. Really,
>> how are they useful?
> Error handling could be useful and you don't _have_ to use it. It's
> just a good way to allow communication between the xfconf backends and
> the user, when needed.
True, but I don't see how these errors would be useful to the user:
1. A problem with the xfconfd daemon. Well, "we can't talk to the
daemon" is about the only error message you're going to get here, which
isn't so useful. If config files are corrupted, that's a daemon error,
not a client library error.
2. Property doesn't exist on Get(). This isn't really an error, and
the API provides for fallback values when the property doesn't exist.
If you really must know if a property exists or not, there's
3. Property doesn't exist on Remove(). So what? The result of the
operation is the same: the property is not in the config store after
calling remove(). And if remove fails for another reason, is the client
going to care? I don't think 'providing a message to the user' (why
would you want to, anyway?) is a good reason to have error returns.
> Personally I'd like to know when something failed and better tell the
> user something when wrong (no write permissions with a file backend),
> before he/she loses information, but maybe I'm a bit GError addicted,
> duno, /me just likes it ^_^ and IMHO it's the cleanest wait of error
> handling in a library.
All the _set() functions return a gboolean. The *reason* why the set
failed isn't so important. For GUIs that wish to disable GUI elements
for settings that have been locked by an administrator, there will be
API for this: xfconf_channel_is_writable() and/or
xfconf_channel_property_is_writable(). You're not going to set out to
determine if a property is writable by trying to write to it; you're
going to ask in advance.
I agree that GError is great for passing around error information when
you don't have a GUI, but the point I'm trying to make is: the intended
audience that I have in mind for the client library *doesn't care* why
and operation failed when it failed, and in some instances may not even
care whether an operation succeeded or failed. I want to keep this API
as clean and simple and easy-to-use as possible. Error explanations are
just extraneous noise for this application.
Now, if someone wanted to write an app that cares about getting GErrors
back, the dbus interface provides them. The XfconfChannel API is really
a pretty thin layer on top of the dbus interface and it's not very hard
to just take generated glib bindings header for it, and call (e.g.)
More information about the Xfce4-dev