KConfigDialog

[Andreas Pakulat]

On 20.03.07 14:44:00, Aaron J. Seigo wrote:
> 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.

Uhm, the item checks a newly set property value against the originally
loaded value already. So that part works, unless I misunderstood you.

> 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?

Well, in KDevelop4 we may need something similar. We currently have a
settings dialog which also includes project-specific stuff. And we
support multiple projects. Now the settings dialog is non-modal so a
user could change the project and then the settings dialog should be
updated with the values of the new project, possibly asking the user
wether the current settings should be saved.

Andreas

-- 
Troubled day for virgins over 16 who are beautiful and wealthy and live
in eucalyptus trees.