Review Request 123705: Add 2nd variant for KConfigGui::sessionConfig()

[David Faure]

> On May 9, 2015, 7:42 p.m., David Faure wrote:
> > With this API change, I wonder if it makes sense for kconfiggui.cpp to retain ownership of the KConfig object. Wouldn't it be safer if the caller got ownership of it, saved into it, and then discarded the KConfig instance? Then we wouldn't have this "lose unsaved changes" code path. Or is the idea that multiple parts of the code could connect to the qApp signal, so they should share the same KConfig instance?
> 
> Stefan Becker wrote:
>     I understood that KConfigGui is responsible for the applications' session configuration. I.e. there are the following situations:
>     
>     1. application started without -session command line argumen:t KConfigGui::sessionConfig() must never be called. That's what canBeRestored() is all about.
>     2. application started with -session command line argument: KConfig::sessionConfig() needs to create KConfig object based on that name so that the application can restore its state.
>     3. session manager emits saveStateRequest signal. At this point the old session config file has become obsolete and a new one needs to be generated -> KConfigGui::sessionConfig(&sm).  The application must file that KConfig object with the new status. If code calls KConfigGui::sessionConfig() it must return the new object.
>     
>     I agree that if kxmlgui KMainWindow is the only user of KConfigGui then the code could be refactored to squash KConfigGui into KMainWindow. But IMHO that is beyond the scope of this bug/review.
> 
> David Faure wrote:
>     It should definitely be possible to do session management with KConfig and without KXmlGui. I wasn't suggesting otherwise.
>     I was only suggesting to move ownership, i.e. KConfigGui::sessionSavingConfig() saying "the returned KConfig instance is yours, you must delete it once you're done with it".
>     But I'm not 100% sure about this idea. In fact it would break the case were independent slots want to save stuff, so let's forget about that idea.
>     
>     Your description does confirm my thinking that the new method should rather be called something like sessionSavingConfig(). Different signature, different method name, different purpose, different filename... and different underlying KConfig object.
> 
> Stefan Becker wrote:
>     OK, but sessionConfig() must still return the new object. Just in case some other code in the application calls that function after sessionSavingConfig(sm&) has been called.

Ah I see what you mean. This bugfix in the libs doesn't change what apps do. My idea (splitting loading and saving) is too radical at this point then.

Maybe KConfigGui's new API should look more like a setter then, if we are changing state.
(We are not just requesting something, that method changes what sessionConfig() returns.)

So maybe the new method should be setSessionConfig(QSessionManager) (but the naming isn't great) or maybe setSessionConfig(QString) and the caller (xmlgui) would use KConfigGui::setSessionConfig(KConfigGui::sessionConfigName(QSessionManager)).


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123705/#review80136
-----------------------------------------------------------


On May 10, 2015, 10:30 a.m., Stefan Becker wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123705/
> -----------------------------------------------------------
> 
> (Updated May 10, 2015, 10:30 a.m.)
> 
> 
> Review request for KDE Frameworks and Rex Dieter.
> 
> 
> Bugs: 346768
>     https://bugs.kde.org/show_bug.cgi?id=346768
> 
> 
> Repository: kconfig
> 
> 
> Description
> -------
> 
> When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new variant that accepts the session manager object.
> 
> 
> Diffs
> -----
> 
>   src/gui/kconfiggui.h 173400f 
>   src/gui/kconfiggui.cpp 0048c60 
> 
> Diff: https://git.reviewboard.kde.org/r/123705/diff/
> 
> 
> Testing
> -------
> 
> On F22 with kwrite & konsole
> 
> 
> Thanks,
> 
> Stefan Becker
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150510/ad92f8ba/attachment.html>