<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Stephan Arts wrote:

<blockquote

 cite="mid:74b8614e0707091336i7fa0c7afpaeb1a722114c0867@mail.gmail.com"

 type="cite">

  <pre wrap="">On 7/9/07, Harold Aling <a class="moz-txt-link-rfc2396E" href="mailto:h.aling@home.nl"><h.aling@home.nl></a> wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap=""> 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'...

 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...

    </pre>

  </blockquote>

  <pre wrap=""><!---->

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.

  </pre>

</blockquote>

What about including some specification file (xml?) and upon removal of

that file, purge the settings from the store?<br>

<br>

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...<br>

<br>

-H-

</body>

</html>