[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:       Daniel Molkentin <molkentin () kde ! org>
Date:       2001-07-25 22:14:19
[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).

This is exactly what I want for KControl. This would make maintaining it a 
_lot_ easier.

>
> 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.

Yes, something like that.

>
> You won't replace all config dialog GUI elements with this approach,
> but you abstract away all the boring ones, esp. if "group" and "key"
> are designable QProperties, so you can use the QtDesigner :-)

Well, having XML files describing options would be the most ideal state.
I don't know how far this can be supported in Designer2.

With config options described in XML, KControl's keyword search could
return an individual collection of all matching options created on the fly.

But even if it is possible I don't know if its woth the effort to go that far.

Greetings,

</daniel>

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