Experiences with KDE-CVS at LinuxWorldExpo

[Waldo Bastian]

>>  in a global config would disallow the
>>  application to write sections or disable the checkbox, radiobutton,
>>  whatever at all so the user knows, ok, I can't change that because
>>  I'm not allowed to.
><snip>
>
>It's a PITA to write even moderately sized config dialogs with taking $i
>for key and group into account. Not mentioning the added complexity for
>the actual logic of the config dialog:
>
>myConfKeyWidget->setEnabled( config->entryIsImmutable( "myConfKey" ) );
>
>and then checking whether or not the enabled state of myConfKeyWidget is
>due to GUI or config key restrictions. Plus adding visual feedback of
>why that widget is disabled (admin did that).
>
>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.

I'm afraid that requires having KRadioButton, KCheckBox etc..

An interim solution could be to only support immutable groups and 
disable complete tabs/pages based on that, but that only works if the 
settings in a config-group more or less have a 1:1 mapping with a 
corresponding tab/page in the config dialog.

Cheers,
Waldo