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

[Marc Mutz]

On Monday 11 November 2002 12:17, Waldo Bastian wrote:
<snip>
> >As it's now, the admin who uses $i to make the account settings of
> > KMail immutable gets himself more work than he saves, what with all
> > the users phoning the helpdesk with "Kmail doesn't remember my
> > account settings" complaints.
>
> Yes, this is a big problem. The solution would be something like
> marking every GUI element with some sort of tag that identifies the
> config option it belongs to and then have some behind the scene magic
> that automatically disables/enables GUI elements according to it's
> immutable state. That way the programmer would only need to tag the
> various elements with the right config options.
<snip>

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.

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.

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).
2. Config-aware widgets
3. Change notification for KConfig keys and groups
4. A ConfigureDialog class that takes care of handling apply, cancel and 
"set defaults"

1 and 3 are needed to move "config manager" functionality into KConfig, 
1, 2 and 4 are needed to ease the development of config dialogs that 
correctly react on immutable keys (and BTW: on read-only KConfigs).

Marc

-- 
"Similia similibus currentur"
           -- Bush's new motto in fighting terrorism.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021111/8ec7814e/attachment.sig>