Re: config library idea

[Tom Tromey <tromey cygnus com>]

Havoc> Now there's no way to get rid of legacy formats, but we could
Havoc> make it easier to avoid this problem with new applications by
Havoc> separating the gnome-config facilities from the rest of gnome
Havoc> and making them available to application writers.

One positive effect of the current system is that if we change
gnome-config, then we know where to look to fix a large part of the
code that uses it.

That doesn't mean I think your idea is bad.  Quite the contrary.
However, I think we ought to make sure that the API we are publishing
and promoting is one that we can actually live with in the long term.

So really I'm wondering if we should make some changes to gnome-config
before doing this.

For instance, I'd like to be able to have my program be notified when
a config option changes.  E.g., there could be a config object which
would emit a signal when a property I care about changes.  In the
short term this could be done by polling the files; in the long term
it could be done through CORBA.

Havoc> Two other ideas: fold gnome-config into glib instead of making
Havoc> it its own mini-library, and/or work with WindowMaker's
Havoc> libPropList and add some of the features from there (e.g. it
Havoc> looks like it handles tree-shaped data a lot better).

Miguel recently asked about adding libPropList to the tree.  Dunno
what's going on there.

Tom