[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Re: KConfigXT and settings external changes
From:       Kevin Funk <krf () gmx ! de>
Date:       2011-09-06 12:36:29
Message-ID: 1659770.4QqWMgvuOg () kerberos
[Download RAW message or body]

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 <<
[prev in list] [next in list] [prev in thread] [next in thread]