KConfigDialog

Aaron J. Seigo aseigo at kde.org
Tue Mar 20 20:44:00 GMT 2007


On March 20, 2007, Martin Heni wrote:
> Unfortunately, the dialog checks quite thouroughly whether it is already
> open etc and prevents any further updates to the dialog. At least none

this does obviate the need to resolve conflicting changes. in teh case a 
checkbox, for instance: the user opens a configure dialog and enables an item 
by clicking a checkbox; the program, meanwhile, (for whatever reason) 
sets/re-loads a setting in the kconfigskeleton, prompting an update in the 
dialog; what happens to the checkbox? the user's setting should remain and 
the Ok/Apply buttons should still be enabled. this means tracking the changed 
state of each widget. right now it just compares the existing widget's 
property value to that of the kconfigskeleton item's value, which obviously 
wouldn't be enough anymore as one would also have to check against the 
originally loaded value.

so ... looks like there is more work to be done there to make this work 
as "naturally" as one would expect as a user.

what is the use case(s) you have in mind where the non-updating nature of the 
dialog is problematic?

> It would be useful if the KConfigDialog would allow access to its 
> KConfigDialogManager's updateWidget() etc procedures [which set the dialog 
> GUI according to the KConfig data]. Ideally by using a SLOT which could be 
> connected to the KConfigSkeleton configChanged() signal. 

this will result in another pass over the widgets when saving the settings 
from the dialog (Ok button -> updated kconfigskeleton -> configChanged() 
emitted -> dialog updates widgets), though i suppose the overhead of that is 
nominal.

> To allow this the KConfigManager needs to allow access to its updateWidget
> stuff. One possibilty would be to use the updateWidget() function of
> KConfigDialog which is already available as SLOT but not used directly. A

this won't work out very nicely, as then every subclass that implements 
updateWidgets() itself will have to call the parent's method manually, which 
is a subtle API change but a big behavior change (bad combo =) which will 
innevitably lead to bugs.

i'd recommend creating a new non-virtual slot that calls updateWidgets().

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070320/3611599c/attachment.sig>


More information about the kde-core-devel mailing list