RFC: KConfig XT (KDE 3.2)

[Cornelius Schumacher]

On Sunday 16 March 2003 14:19, Benjamin Meyer wrote:
> On Saturday 15 March 2003 6:32 pm, Cornelius Schumacher wrote:
> > On Saturday 15 March 2003 16:38, Waldo Bastian wrote:
> > > * Have the default value for config entries defined in 1 place.
> > > Currently it is not uncommon to have them defined in three
> > > places: 1) In the application that reads the setting in order to
> > > use it 2) In the settings dialog when reading the setting
> > >   3) In the settings dialog when selecting "Use defaults".
> >
> > One solution to that problem is in libkdepim/kprefs.{h,cpp} and
> > derived classes. It also solves the problem of having to know the
> > type of the config value at different places in the code.
>
> Wow!  Yet another configuration helper class. :-D

KPrefs has been there for more than two years, so it's probably not 
really "yet another" ;-)

> After looking at KPrefs I like what it does, but don't think it is
> needed because of what KAutoConfig does and how it integrates into an
> application. As I have been converting applications I have found that
> in general in a window/widget you will have a readSettings() function
> which will directly call readConfig() for the 10 or so settings that
> are read for that widget. That is all that the programmer has to do. 
> The setting of defaults, reading, writing, immutability, is
> automaticly handled by KAutoConfig.  Thus creating a kpref's class
> would be kind of silly sense it would only used once.

KAutoConfig doesn't address access of config options in the application 
outside the config dialog. This is the main point of KPrefs. There is 
another class in libkdepim (KPrefsDialog) which also addresses the 
config dialog by providing standard widgets accessing the KPrefs class. 
This makes it very easy to add new config options by just adding a few 
lines of code defining names, default values of the options and layout 
and grouping of GUI elements.

With KAutoConfig you still have to duplicate all the code reading config 
options for use in the applications including default values. It also 
doesn't help at all for config options which don't have a GUI to set 
them.

I think the goal of a config helper class should be to have only a 
single place where the name of the entry in the config file and the 
default value are defined, to provide easy and typesafe access in the 
application code and to allow different ways to create a GUI for 
setting the options, e.g. no GUI at all, handwritten dialogs, designer 
generated code or partly of fully autogenerated dialogs.

> See my comments above.  It is just too hard to create a clean ui from
> xml and it is so much easier/faster (both in execute and development)
> to have a ui file.

How hard it is to generate a clean GUI depends on how much information 
you put int the source files. ui files are an example where very 
detailed information is put in the xml file the GUI is generated from. 
There certainly are other ways to generate clean GUIs (partly) 
automatically from much more simpler xml files than the designer ones.

-- 
Cornelius Schumacher <schumacher at kde.org>