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

List:       kde-core-devel
Subject:    Re: RFC: KConfig changes for 3.0
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-07-25 21:24:17
[Download RAW message or body]

On Wednesday 25 July 2001 16:03, Marc Mutz wrote:
> On Wednesday 25 July 2001 14:10, Simon Hausmann wrote:
> <snip>
>
> > IMHO the right fix is not to enrich the kconfig file but to add a
> > proper GUI.
>
> <snip>
>
> Off the topic of this thread, but related:
>
> Often, certain GUI elements in the config dialog correspond directly
> to a certain config key (e.g. QCheckBox <-> bool entry; QLineEdit <->
> String entry).
>
> How about ready-made ConfigWidgets that can be given KConfig*, group
> and key, and then plugged into the config dialog, getting their label
> from the database of explanations Simon mentioned. On Apply, Cancel,
> Default, the dialog makes sure these widget's states are being
> reflected into the config file.

I have written something like that for KOrganizer and Kandy. Two main 
base classes are provided, one for the GUI part (KPrefsDialog) and one 
for the non-GUI part (KPrefs) plus some additional small classes 
representing bool, int, string, font, color etc. entries and their GUI 
representation. To use this in an application you inherit from the two 
main classes and add the configuration options in the constructor.

With this approach you have to define the attributes of the config 
option (like name and default value) only once, no more duplication of 
config entry names etc. The code for reading/writing the config file 
and the representation in the config dialog are in the base classes and 
you don't have to care about that. This makes the use of configuration 
much more simple if you have to do everything by hand and gives a 
consistent behaviour and look.

The classes work well, but do not cover all kind of options. They could 
also need some more documentation. If there are other people interested 
in using these classes, I could add the missing parts. Comments are 
welcome.

-- 
Cornelius Schumacher <schumacher@kde.org>

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