Review Request 119792: Save the view states in addition to the view urls and splitter state in DolphinTabPage.

Frank Reininghaus frank78ac at googlemail.com
Fri Aug 15 12:08:48 BST 2014


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


Thanks Emmanuel - this is indeed a very nice change, and I can confirm that it works nicely!

The only possible problem that I see is the versioning of the data format that is used by DolphinTabPage::saveState() and DolphinTabPage::restoreState(const QByteArray&). Since the QByteArray is written to disk when saving the session and then read again when the next session is started, we cannot be sure that saving and loading the data is done with the same Dolphin version.

The session management issue has already caused https://bugs.kde.org/show_bug.cgi?id=338187 - that one was easy to solve because the QByteArray simply wasn't there in older versions, so checking in the function if the QByteArray is empty was enough to fix the problem and prevent crashes.

The versioning issue gets more tricky when new items are added to the QByteArray though, in particular if a new entry is inserted between existing entries, like the view state of the first view, which is now in front of the information for the second view.

Moreover, we also have to care about the versioning of the DolphinView state now. Up to now, the QByteArray that keeps the DolphinView state was never written to disk, so we always new what format the data is stored in.

I'm not entirely sure what the best solution is. One could store an int that identifies the stream format version as the first item in the QByteArray. But then we would need special compatibility hacks because Dolphin 4.14.0 does not store such an int in the stream. I'll try to think about it some more, but if you or anyone else has an idea, that would be very welcome as well, of course.

In any case, I think that we might want to add a DolphinMainWindow unit test that calls DolphinMainWindow::readProperties(const KConfigGroup& group) with KConfigGroups that have been created with different versions of DolphinMainWindow::saveProperties(KConfigGroup& group). Maybe even with KConfigGroups that have been modified in some way, because one could argue that we should not get a crash even if the user or a malicious program messed up the session data on disk.

- Frank Reininghaus


On Aug. 14, 2014, 6:40 p.m., Emmanuel Pescosta wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119792/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2014, 6:40 p.m.)
> 
> 
> Review request for Dolphin.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> -------
> 
> Save the view states in addition to the view urls and splitter state in DolphinTabPage.
> 
> Previously closed tabs can now be exactly restored. (same as in e.g. Firefox)
> 
> This is also great for session management, because you can continue your work exactly where you left it. :)
> 
> 
> Diffs
> -----
> 
>   dolphin/src/dolphintabpage.cpp 3d1ba5a 
> 
> Diff: https://git.reviewboard.kde.org/r/119792/diff/
> 
> 
> Testing
> -------
> 
> 1. Expand some folders, set a item somewhere in the list as current item and scroll to a random position (also in split view)
> 2. Close this tab
> 3. Reopen the previously closed tab
> 4. Check if all previously expaned folders are expanded now (same with current item and scroll position)
> 
> Works for me!
> 
> 
> Thanks,
> 
> Emmanuel Pescosta
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20140815/1d1f21cc/attachment.htm>


More information about the kfm-devel mailing list