On Tuesday 06 September 2011 00:14:21 Milian Wolff wrote: > Milian Wolff, 06.09.2011: > > Francesco Di Muccio, 05.09.2011: > > > Hello all, > > > > > > In my application I'm using KConfigXT, everything works fine when I > > > change the settings values from the dialog inherited by > > > KConfigDialog, > > > but if I write the configuration values using the class generated > > > from > > > the kcfg file the changes are not reflected into the settings > > > dialog. > > > Here is the flow: > > > > > > 1) Open the settings dialog (it will be cached by KConfigDialog), > > > change some values and close it > > > 2) Call some code that writes the same values using the class > > > generated by kcfg generator > > > 3) Reopen the dialog cached instance. The values shown by the > > > widgets > > > are the old ones. > > > > > > I read the docs and the tutorial at > > > http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT, but > > > didn't find anything that pointed me to a wrong use of the > > > framework, > > > so maybe it is a bug. > > > > > > To be sure I read the sources of KConfigDialog and maybe spotted the > > > problem: in KConfigDialog::showEvent() there is a check to a boolean > > > flag KConfigDialog::KConfigDialogPrivate::shown that get set to > > > true at the end of the method but never set to false. > > > In the showEvent() method there is the code that updates the widgets > > > according to KConfigSkeleton state. Since "shown" is never set to > > > false that code will not be executed the next time the > > > dialog->show() > > > is called. > > > I didn't find a way to force KConfigDialog to update the widgets; > > > the > > > responsible to update them is KConfigDialogManager and it's enclosed > > > in KConfigDialog::KConfigDialogPrivate. > > > > > > I did an ugly hack to make it work: discarding the cached instance > > > in > > > place of a new one each time the settings dialog is opened. > > > > > > I didn't fill a bug report because i was unsure if it was an > > > expected > > > behavior or not. Am I missing something? > > > > Do you ever call YourConfig::writeConfig() ? > > > > Otherwise take a look at e.g. > > > > https://projects.kde.org/projects/extragear/sdk/massif- > > visualizer/repository/revisions/master/changes/app/configdialog.cpp > > and > > https://projects.kde.org/projects/extragear/sdk/massif- > > visualizer/repository/revisions/master/changes/app/mainwindow.cpp > > > > it works like a charm there. To be honest though I'm not sure whether I > > leak the settings dialogs in app::preferences, I should investigate that > > > > :) > > Ah ok - I delete the dialog on close (via the attribute). Probably that is > all that is required? > > bye
Yep, although I would not set the attribute in the dialog's constructor. For external users of your class it is quite hidden and modifies normal behaviour. Assume: ConfigDialog* dlg = new ConfigDialog(); dlg->show(); // ... // dlg gets closed // ... delete dlg; // error: double-free Better do: ConfigDialog* dlg = new ConfigDialog(); dlg->setAttribute(...); // so people *know* it's getting deleted. Not a serious issue after all. Sorry for the nit-picking, I was bored. Greets -- Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
