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