Re: Running vs starting apps [rambled to: global shortcuts]

[Christian Rose <menthos menthos com>]

I don't know if I've understood the basics of GConf correctly (please 
correct me if I'm wrong) but GConf currently uses XML for everything.
And, due to the wonders of XML, this means that it is at least 
theoretically possible to edit with an ordinary text editor or use 
another suitable XML-parsing tool.

So at least we're not yet at the point of the 
"only-one-single-binary-database-that-if-you-screw-it-screws-everything-and
it-is-only-to-be-edited-with-one-single-gui-tool-don't-you-dare-using
something-else" horror that is the Windows registry.

However, on the http://developer.gnome.org/feature/current/index.html 
URL that Blair Strang so kindly provided, there is talk about how GConf 
is aiming to be a front-end to other database solutions in addition to 
just XML:

"GConf currently has a single backend that stores configuration data in 
XML-format text files; however, the architecture allows a Registry-like 
binary database backend, an LDAP backend, or even a full-blown SQL 
database backend. The backend used is configurable by the system 
administrator. This is a valuable feature for IS deparatments managing 
large numbers of computers."

But I would not suspect that GNOME would ship and require a full-blown 
SQL database server just to work, even far into the future, or even a 
Windows registry solution with a binary database. I think most 
developers share your (and my) belief in software that, no matter the 
other programming interfaces and user interfaces for configuration, is 
still configurable by hand with just a text editor. I think that's one 
of the reasons why XML has become so popular.


Christian



David Grega wrote:

> I'm okay with Gconf except for one thing that was alarming to me - it'll be 
> like a Windows registry!  I do not have much experience programming on 
> Linux but as a Windows programmer, I 99% of the time use .ini files for my 
> configuration because it's faster!  A registry tends to be big bulky and 
> incredibly and irritably slow on systems that are actually used (not 
> Microsoft prototypes).  I just thought I'd throw that into the list for 
> possible discussion.