Re: [Usability]From application- to user-centric configuration



On Sat, Mar 09, 2002 at 11:12:22AM -0300, Daniel F Moisset wrote:
> On Fri, 2002-03-08 at 14:01, Tommi Komulainen wrote:
> > When
> > I want to try some other mail client I only wonder why I have to do that
> > all over again.  Didn't I just configure a mail client?  Why can't the
> > applications share that configuration?
> > 
> > Do you think something like this could be used in GNOME?  I think it
> > would significantly reduce the configuration effort of users.  Diversity
> > and having the possibility to choose are good, but when you have to
> > repeat everything again and again for every choice, it becomes a PITA.
> 
> I think it should be done at a lower level than GNOME. Because, for
> example, i would like to set my desktop background at gnome, and then
> have the same if one day i want to use kde, or windowmaker.

I totally agree with the sentiment.  It should be common to all
platforms, not just GNOME.  However, I don't think that a change of such
scale is ever going to happen if you don't have working code to prove it
actually works.  (Existing systems already work, why break them?)  Once
it has been established (in GNOME perhaps?) maybe then there's a chance
of wider adoption.

And yes, there should definitely have to be an API for configuration
settings.  No more launch $EDITOR, wonder what the syntax was again, and
so on.  Why are all applications doing their own configuration parsers
anyway?  Remember, "Do one thing and do it well?"  Anyone? :)  Well, in
console that is :-/

Well, in GNOME and KDE too, actually.  Both of them have their own
configuration API, don't they?  Why are they separate in the first
place?  Wouldn't it be possible to remove the GNOME/KDE specific
framework stuff and put the configuration handling in platform
independent library and then wrap that library in the GNOME/KDE
framework?


GConf is a good thing, however.  I'm happy if this could be adopted in
GNOME, for a start.  For console GConf brings just too many library
dependencies, so I don't think it is ever going to be used in mutt, for
example.  Some lightweight file-based configuration library might do it.
Then you'd just have to wire up GConf to use the same backend for the
same parts of the configuration.  Or something.


> If you're interested, you can read it at:
> http://www.grulic.org.ar/~dmoisset/lcf/doc/design.html

I quickly glanced it through and it looks a lot like what GConf already
does.  The only things that I, with my limited knowledge about GConf,
noticed is missing from GConf is the links.  Not sure if that's even
relevant, just define a common practice for defaults, or structure for
common settings.  The need for configuration translators and file
locations are common regardless of the scheme used.

That said, I think for now GConf is the right way to look at.  If you
have time, which you don't, maybe try to make the lightweight library.
After all, the location of configuration files is not that relevant
anymore if you have the library API.


-- 
Tommi Komulainen                                 Tommi Komulainen iki fi
GPG 1024D/68388EE6    6FD6 DD79 EB38 BF6F 3533  09C0 04A8 9871 6838 8EE6

Attachment: pgpJrRUtfnUc9.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]