MCS design proposal

[Stephan Arts]

On 7/9/07, Jannis Pohlmann <jannis at xfce.org> wrote:
> 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.

Then how about adding a remove function to the API? Combined with the
option to list all nodes, it is theoretically possible to clean up the
settings by hand (or a shell-script).

>
>   - Jannis

Stephan