Application Settings for XFCE 4.6

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 8 Mar 2007 00:21:08 +0100 Stephan Arts wrote:

>IIRC, benny once suggested using DBUS for settings-management, i
>really liked this idea.
>What do you think about specifying a D-BUS interface for
>settings-management, and let a (separate) daemon(s) handle these
>settings in the background? Possibly separate MCS-daemon and an
>XSETTINGS daemons?

Whether or not to use D-Bus (I think probably we should) isn't really
the issue: defining a D-Bus interface and writing the glue code for
that is trivial.  Ideally an app using a client-side API for the config
system won't know or care that it uses D-Bus for communication (just
like libxfce4mcs-client doesn't expose its transport mechanism to
applications).

Designing a new configuration system (or picking an existing one and
modifying it to our needs) is the hard part.

Anyway, this libmcs thing seems not that useful for us.  As Jannis said,
it basically just looks like a semi-fancy XfceRc where you can have
multiple config backends.  I don't think we really care about that kind
of thing.

Here's what I think would make a good config system for us:

- --> Daemon

* Single non-GUI daemon that handles just storage, query, and
notification of settings.

* Daemon can be a proxy for a separate XSETTINGS daemon.

* No distinction between manager and client (like in current MCS).  Any
application can change any settings it wants.

* Perhaps have the concept of a 'private' settings channel which isn't
exposed to anything but the single application that accesses it.  (I'm
not 100% sure what I mean by this; just something that occurred to me.)

* The settings available for a particular application are defined in a
text file rather than in the source of the settings panel, as it is now.

- --> Settings manager

* Settings manager GUI is just an application, not part of the daemon.

* Settings manager has settings panel 'applets' which are just normal
programs launched by the settings manager.  Settings applets are
registered by dropping a .desktop file in a special location.  All the
settings manager does is provide a button (or whatever) for that item
and launches the appropriate application.

- --> Client API

* Option 1: Client API can make use of the same model as current MCS,
so we have stuff like:

XfceSettingsChannel *channel = xfce_settings_channel_open("foo");
gchar *setting = xfce_settings_lookup_string(channel, "bar-setting");
xfce_settings_set_string(channel, "bar-setting", "cheese");
g_object_unref(G_OBJECT(channel));  /* closes and frees channel */

... or something like that.

* Option 2: Client API is a global area namespaced by the setting name
itself, like:

gchar *setting = xfce_settings_lookup_string("/foo-app/bar-setting");
xfce_settings_set_string("/foo-app/bar-setting", "cheese");

Maybe have a global settings singleton object to represent a
connection to the settings store; dunno.

* Option 3: ...?


IMHO, *this* is the kind of stuff we want to be talking about.  I
recall Benny wrote something as a proof of concept (based on his own
ideas) a very long time ago; we should dig that up and look at that as
well (I think I have it floating on my HD somewhere).

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF71n96XyW6VEeAnsRAm4LAJ9cHFWoyZ9YiTwn2Opjqrg6mZxl3QCfYVEo
loSq2sI7W0KqgzwOI3juyMc=
=/K4Q
-----END PGP SIGNATURE-----