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.

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.


- 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/67cc57ab/attachment.html>