Kevin Funk, 06.09.2011: > 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.
Hehe no problem. But keep in mind that "users of my class" == "me". But I agree, probably I don't need that custom class at all and could just set the attribute on the parent class. bye -- Milian Wolff m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
