KConfigDialog

[Martin Heni]

There have been some good remarks posted about my suggestion to KConfigDialog. 
I think it sums up to one of the following options:

1.  KConfigDialog does and should not permit settings changed by the program. 
This makes sense in a way as it is a user config where maybe a program should 
not interfere with.
However, in this case this restriction should be added to the API DOC (if not 
even enforced by the dialog). Programs changing the dialog need to be changed 
so that these config options are removed from the dialog and moved to another 
menu item.
Worst case is here if a program does change setting and they are not reflected 
in the dialog (as currently can happen). Then dialog and settings are 
different without the user knowing, which is confusing, especially if the 
dialog is open and shows the wrong settings.

2. Leave the dialog as-is but add to the API DOC that if necessary the dialog 
can be changed with direct access to the UI elements. That's how it is now 
handled by some programs. It works but requires access to the autocode 
generated UI element names, which can be error prone. This requires no code 
change to the dialog but I would add a comment to the API doc to point out 
the problem and this solution.

3. Implement an additional slot which updates the widget like I described in 
my previous posting. The responsibility is then up to the programs and coders 
to use this in a decent way. This works like 2) but with a cleaner interface. 
(Using the existing slot updateWidgets() I agree is not so wise. So we would 
need a new one)

4. Recode the dialog so that it can handle program and user changes. Possible 
solutions have been posted in this thread. This would be the most elegant 
solution but a lot of work for probably relatively few use-cases. I assume 
nobody has time to do this, right? ;-)

How do we proceed now?