Experiences with KDE-CVS at LinuxWorldExpo

[Josef Weidendorfer]

On Monday 11 November 2002 12:17, Waldo Bastian wrote:
> >>  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..

I don't think we need this fine assoziation widget-config option.
What about a ConfigAwareDialog class with a instance for a set of  config 
aware options?
You would specify the names of the widgets of the dialog to be created 
together with config options and immutable flags. Directly after dialog 
creation, this class modifies the created dialog (enabling/disabling widgets, 
perhaps extending the "What's this" help why the widget is disabled...).

This class could even be extended for further general functionality.
* If you specify per config documentation, the "What's this" help of widgets 
could be created completely automatic. 
* If you specify type and allowed ranges for config options, range checking 
and writing of the options could be done automatic.
* If you specify defaults of config options here, this class could do the 
reading of the options itself. A "writeAllDefaultsWithDocumentation" function 
could write a config file for support of an external KConfigEdit application 
(with documentation, allowed ranges; I think KConfig would have to be 
extended to allow writing some formatted comments for options, specifying the
docu, range, type, default in a comment without forcing a value - this would 
be parsed by KConfigEdit).
* A DCOP interface for changing config options of an application could be 
added (able to supply documentation for options...)


I would like to see such a class grouping some config options in a more 
general way not only for real config options of the app, but also for 
attribute settings of a KAction. E.g. "OpenFile" could have a attribute 
"filename".
This is especially important for (DCOP) scripting. 
There should be a way to allow for immutable attributes of actions.

The execution of an Action with unspecified attributes even could create a 
dialog magically on its own before execution.

Perhaps I'm dreaming...

Josef

>
> Cheers,
> Waldo