MCS design proposal

Jannis Pohlmann jannis at xfce.org
Mon Jul 9 22:57:36 CEST 2007


Am Mon, 09 Jul 2007 22:41:58 +0200
schrieb Harold Aling <h.aling at home.nl>:

> Stephan Arts wrote:
> > On 7/9/07, Harold Aling <h.aling at home.nl> wrote:
> >   
> >>  Bo Lorentsen wrote:
> >>  Brian J. Tarricone wrote:
> >>
> >>
> >>
> >>  We don't need anything fancy. Xfsettings or XConf or whatever is
> >> fine. There's no need to come up with special terminology to
> >> replace 'channels', because the term is more or less unimportant
> >> now. If you really want to, just use something like 'config
> >> nodes', since it really is a true tree of preferences.
> >>
> >>  I like the simplicity of XConf, very few would misunderstand the
> >> purpose of that system, and it sounds like GConf, but it is what
> >> it does.
> >>
> >> /BL
> >>
> >>  Also, if 'xfce' or 'xf' is part of the name, non-xfce
> >> applications/users may think twice before installing/adopting it
> >> in their applications. XConf could be seen as a standard X
> >> configuration store, hopefully without Xfce dependencies (or as
> >> less as possible)... My vote goes to 'XConf'...

Personally, I'm against XConf or Xfconf or stuff like that, simply
because it is too close to GConf and might lead to even more people
saying that Xfce is just a copy of GNOME.

I also don't think it's necessary to have the "X" in the name at all
since the system could be used by non-X programs as well. Please
remember this.

Anyhow, I'm bad at names: my only idea so far was "xfcettings" which
sucks as well.

> >>  Has anyone given any thought how to remove information stored in
> >> XConf? Upon uninstalling an application who uses it, I'd also like
> >> to remove the configuration files/settings...
> >>     
> >
> > Hmm, you mean that when someone removes (for example) the panel, all
> > configuration-entries used by the panel should be removed?
> >
> > This might prove to be difficult since some entries could be used by
> > more then one application at the same time. But if nodes need to be
> > 'registered' before they can be used, the config-daemon can count
> > who registered a node.
> >
> > A command-line app could tell the daemon it should 'unregister' app
> > 'x' for node 'y'. If all registered apps are removed, it can clean
> > up the node.
> >
> > However, this might be a bit complex.
> >   
> What about including some specification file (xml?) and upon removal
> of that file, purge the settings from the store?
> 
> Example: "/etc/xconf/xconf.d/xfwm4" which contains the configuration 
> specification (and defaults) for xfwm4. Upon install, XConf sees the 
> file, adds it to the store and upon deletion, XConf removes the
> entries from the store...

You're missing one of the points of this discussion. GConf has these
kind of specifications - the design we're talking about has not. IMHO
we should keep it lightweight and thus avoid stuff like this.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20070709/75c17591/attachment.pgp>


More information about the Xfce4-dev mailing list