[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-debian-devel
Subject:    [devel] Re: Don't implement config functionality (hardcoding Config
From:       "C. Gatzemeier" <c.gatzemeier () tu-bs ! de>
Date:       2004-01-14 20:29:05
Message-ID: 200401142129.05611.c.gatzemeier () tu-bs ! de
[Download RAW message or body]


I had a look at the "guidance" config tools, are they the ones intended for 
kde-debian?
I had a bad misnomer in my last respose, I'll try to clear that up:

Am Sonntag, 11. Januar 2004 23:53 schrieb C. Gatzemeier:
> Am Sonntag, 11. Januar 2004 23:20 schrieb Simon Edwards:

> > > IMHO the only real solution are config frontends that do not need a new
> > > module for each new thing that one wants to configure.
> > > Meaning no time needs to be used hardcoding any often changing
> > > package specifics into frontends.
> > > 
> > > This can be accomplished if  the specifics are handled for example by
> > > the config4gnu [1] framework. Using it as the backend allows focusing on
> > > all the nice usability and eye candy for the frontend. (just like with
> > > kdebconf)

> > The problem with this approach is that as far as usability is concerned,
> > it only gets you as far as a "windows style" registry editor. Which is to
> > say, not very far at all and certainly not very usable.

Wrongly wrote:
> Certainly not. However if it would not be better than a tree of keys and
> values. 

I am sorry, I meant:

_Even_ if config4gnu would not present more than keys and values to frontends, 
or if a programmer does not want to make use of the provided forms and wizard 
stuctures, it is still beneficial to use config4gnu as backend.

If you don't think so and are working on or intending to write and maintain a 
config tool, I think the time spent grasping how well config4gnu is designed 
is very worthwhile can actually save a real lot of time in the long run.

The more fun part of implementing cool frontends can stay but the work 
implementing specifics should be put and shared in the CFG layer between 
apps.

I think SWIG can easily provide python bindings for CFG, it already generates 
them for perl.

Cheers,
Christian





---- Original Message ----

Concerning the messages about the prospecive kde-debian System Tool. How it 
should look like, integrate, best language etc. And how it is not fun to 
maintain tools for every package one wants to configure:

IMHO the only real solution is a frontend that does not need a new module for 
each new thing that one wants to configure. So that no time needs to be used 
hardcoding any package specifics.

This can be accomplished if  the specifics are handled for example by the 
config4gnu [1] framework. Using it as the backend allows focusing on all the 
nice usability and eye candy for the frontend. (just like with kdebconf)

And if time goes into improving config4gnu, writing initial xml definitions 
for new packages, or even a perl/python/* syntax parser for it, it is well 
spent because any other frontend benefits also. You will benefit in the same 
way from any other contribution to CFG. And if for example the CC frontend is 
droped for a KAdmin frontend in the future the work won't be lost.

Having different frontends to have different (G)UIs is ok but each GUI having 
to maintain modules for each package just not. What do you think?

May a Control Center module to integrate the Config4gnu nodes be sufficient? 
It could be based on a nice html view of CFGs xml-config-representation.

-Christian


[1]  http://linuxwiki.de/Config4Gnu/EnglishFAQ 

_______________________________________________
kde-debian-devel mailing list
kde-debian-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-debian-devel
[prev in list] [next in list] [prev in thread] [next in thread]