config-aware widgets (was: Re: Experiences with KDE-CVS at LinuxWorldExpo)

[Waldo Bastian]

>Which introduces the need for KConfig(Base) to have change notification
>signals for keys and groups. Something like a KDirWatch for KConfig.


>Why? B/c a config key is typically written to in the config dialog and
>read in at least one other place (where it's setting is used). Some
>apps (like KMail) try to get around this by having Manager singletons
>that are responsible for managing a group of releated config options
>and send changed() signals when something changes.
>
>That's so that config key renameing/config file reorganization/knowledge
>or construction of defaults can be located at a single point (=class)
>and that typos end up being compile-time instead of runtime errors:
>
>config->readEntry( "myConfgiKey", myDefault );
>
>is a runtime-error that's quite hard to find.

Change notification will not change that. However, if we have formal 
documentation for config options we can at least detect that this 
option has not been defined.

>If we have config-aware KCheckBoxes, this solves the problem of
>immutable keys being presented correctly in the config dialog, but
>introduces other complexities like having again two places in the app
>code that need to know the config keys and it's defaults.

Those complexities are not introduced by that, we have those today already.

>IMO, we'd need at least:
>
>1. A central XML or whatever file where all config keys are declared
>with type, comment(s) (to be used as What's this help) and possible
>values (complete with enum<->text conversion); something like a XML
>Scheme (which we could possibly abuse for that).

Yes.

>2. Config-aware widgets

Yes.

>3. Change notification for KConfig keys and groups

It would be a nice new feature but I don't think it is very 
important, it is not really hard to send some signals yourself if you 
need that kind of functionality.

>4. A ConfigureDialog class that takes care of handling apply, cancel and
>"set defaults"

Yes.

I wonder if (2) could be handled with (4) as well, as Josef suggests. 
That would make things a lot easier. You get problems when you want 
to disable widgets as part of the GUI behavior as well as due to its 
immutable state, but maybe it works if we can reserve disable/enable 
for GUI behavior and read-only to indicate immutable.

Cheers,
Waldo