Bug 330047 - Dolphin doesn't save/restore both locations in a split view if "Split view mode" is enabled in the settings
Summary: Dolphin doesn't save/restore both locations in a split view if "Split view mo...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: split view (show other bugs)
Version: 4.12.0
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: reproducible
Depends on:
Blocks:
 
Reported: 2014-01-16 22:22 UTC by MountainX
Modified: 2014-02-02 09:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.12.3


Attachments
Possible fix (973 bytes, patch)
2014-01-22 11:24 UTC, Frank Reininghaus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MountainX 2014-01-16 22:22:05 UTC
I use the split view. When I reopen Dolphin I expect both prior locations to be restored. However, the location for one of the two splits is restored to both splits.

Reproducible: Always

Steps to Reproduce:
1. use the split view in Dolphin
2. go to two different locations in each view
3. repeat for another tab (split view, two different locations)
4. log out
5. log back in
6. expected that Dolphin will reopen with the same locations that we being viewed.

Actual Results:  
the location for one of the two splits is restored to both splits. This happens in every tab too. So half the prior locations are lost

Expected Results:  
all prior locations would be restored, even in split views
Comment 1 Frank Reininghaus 2014-01-17 08:31:51 UTC
Thanks for the bug report. This has been reported recently in 193807 comment 2. I could not reproduce the problem at the time. I haven't tried it since then - testing this is obviously a rather time-consuming process.

For anyone who is interested in debugging this problem: the code that handles session-restoring is mostly in

void DolphinMainWindow::saveProperties(KConfigGroup& group)
void DolphinMainWindow::readProperties(const KConfigGroup& group)
Comment 2 Frank Reininghaus 2014-01-17 08:46:34 UTC
That was bug 193807 comment 2.
Comment 3 MountainX 2014-01-17 18:12:55 UTC
I would like to put in some time looking into this. Unfortunately, I'm not a KDE developer. Is it possible to compile a debug version of Dolphin only and run it without replacing my normal Dolphin?

When is DolphinMainWindow::saveProperties called and what calls it? Where are the properties saved?

It would be awesome if I could step through the running code, but I don't have a KDE dev environment set up. Still, I might be able to figure some things out. I could insert some print & log statements into the code and run my debug version of Dolphin.

I appreciate any tips (links, etc.) on getting started.
Comment 4 MountainX 2014-01-17 20:06:10 UTC
I found some stuff here:

http://techbase.kde.org/Getting_Started/Build/Distributions/Debian/Source

And this looks helpful too:
Development/FAQs/General FAQ - KDE TechBase
http://techbase.kde.org/Development/FAQs/General_FAQ#Can_I_have_a_stable_and_an_unstable_KDE_on_the_same_computer.3F
Comment 5 Emmanuel Pescosta 2014-01-17 20:50:09 UTC
Hmm this bug should be fixed in the "emmanuelp/tabhandling" branch of Dolphin ;)
I'll test it this weekend when I have time.
Comment 6 Frank Reininghaus 2014-01-18 16:23:11 UTC
I just tried it with Dolphin 4.12.0 (OpenSuse): opened several Dolphin windows, opened different URLs in the split views. In one window, I opened 4 tabs, 2 of which had split views, all with different URLs. Everything is restored fine after logging out and back in.

(In reply to comment #3)
> I would like to put in some time looking into this. Unfortunately, I'm not a
> KDE developer.

Everyone can become a KDE developer. Your help is definitely welcome!

> Is it possible to compile a debug version of Dolphin only and
> run it without replacing my normal Dolphin?

Yes. This is actually very easy - installing "kdelibs devel" packages, cloning the kde-baseapps respository, running CMake and then make should be enough. However, the session manager will then most likely not run the self-compiled Dolphin when logging in and restoring the session, so it might not help much. Moreover, you cannot make any modifications (like adding debug output) to kdelibs then.

> When is DolphinMainWindow::saveProperties called and what calls it? Where
> are the properties saved?

The class KMainWindow from kdelibs calls it, see http://code.woboq.org/kde/kdelibs/kdeui/widgets/kmainwindow.cpp.html

I don't know where the "properties" are saved, but one can probably find out by going through the source code (most likely, some code from kde-workspace is also involved in this).

> I appreciate any tips (links, etc.) on getting started.

I think the most straightforward way to build KDE from source is to use kdesrc-build:

http://techbase.kde.org/Getting_Started/Build/kdesrc-build

But you have to install all KDE packages in such a way that they are being used immediately after logging in. I'm not sure what's the best way to achieve that and not mess around with your normal KDE setup too much at the same time. Debugging session restoration problems is definitely not an easy task.
Comment 7 MountainX 2014-01-18 16:46:12 UTC
Frank, thank you for your great answer (and for looking into this further). This info will get me started. However, as you point out, debugging this will not be easy, especially with my need to maintain my normal KDE setup too. In the long run, I will try to set up a development-only computer where I can run my own compiled KDE exclusively.

However, I have a suggestion (feature request) that might also directly help with debugging this issue. I would like for Dolphin to have the same sessions features as Kate (see documentation here: http://docs.kde.org/stable/en/applications/kate/fundamentals-using-sessions.html).

With a Kate-like sessions feature in Dolphin, I could save and restore sessions any time. Not only is this a highly desirable feature in general, it would let me easily work on testing/reproducing/debugging the current issue. (And, in fact, if the current issue is just related to restoration after logging in, I wouldn't care because I could manually restore a saved session as I do in Kate. So this feature would be more powerful and useful than strictly resolving this bug.)

Would any of the Kate code be reusable?

If this idea is interesting for you (or any KDE Devs) if you could throw together a first pass, I will do all the testing and help with as much of the development as I can. (The last time I did something like this in a new language/new environment, I eventually ended up finishing the project myself.)
Comment 8 Frank Reininghaus 2014-01-18 17:12:10 UTC
(In reply to comment #7)
> Not only is this a highly desirable feature in general,

I see that this feature might be useful for some users in some situations, but I'm not sure if it will be sufficiently useful to a large user group that including it in Dolphin would be justified. There hasn't been much demand for it in the past (I found these two reports: bug 306257, bug 246028). Moreover, the feature is already available in Konqueror, which is intended as a file manager for users who need more flexibility than Dolphin can provide (e.g., more options to split views, sessions, which are called "Profiles" in Konqueror, etc.).

I'm not so much concerned about the effort required for the implementation. It's rather the cluttering of the GUI and the long-term maintenance of the new code that I'm worried about.

> it would let me easily work on testing/reproducing/debugging the current
> issue.

I see no reason to assume that the proposed new "session" feature and the "session restoration", which look similar at first sight, but have very little in common implementation-wise, would suffer from the same bugs.

> Would any of the Kate code be reusable?

No idea - I don't know the Kate code.
Comment 9 MountainX 2014-01-18 19:02:58 UTC
Thanks again for replying, Frank. I'm sure you are right about most of this.

However, I'm still convinced that Kate-like sessions in Dolphin would be a killer feature. I just read this article: "aseigo: Kate has won" (http://aseigo.blogspot.com/2013/11/kate-has-won.html). In that article Aaron specifically mentions the Kate sessions feature as critical in his decision. 

I believe "Dolphin with sessions" would win Dolphin new fans for Dolphin in the same way the sessions feature is doing for Kate (see comments to the article above). It is really a killer feature.

I have been playing around with Konqueror as a file manager for the last hour.  It appears to share many underlying components with Dolphin. Unforunately, Konqueror isn't as good at managing files as Dolphin. For example, in the split view Konqueror only shows one location bar. This is a consequence of it's design as a web browser too. What this means is that you cannot determine which two folder locations are open at a glance as you can in Dolphin.

I could make a big list of reasons why Dolphin is the better file manager, but I assume that has already been done -- afterall, Dolphin is the default in KDE now.

"Dolphin with sessions" would still be Dolphin, but it would add just one killer feature that would be as important in Dolphin as it is in Kate. 

Dolphin and Kate are both highly focused tools and extremely good at what they do. Both should have the sessions features. That would increase UI consistency and functionality across core KDE apps. 

I also get the feeling that the "Profiles" feature in Konqueror might provide much of the code. Or maybe there is a component that could be reused...

Would you (or anyone) be interested in implementing this feature in Dolphin if I put a bounty on it and agree to help extensively with testing?

Anyway, thanks for all the comments and educational info you have provided.
Comment 10 Frank Reininghaus 2014-01-19 22:49:34 UTC
(In reply to comment #9)
> However, I'm still convinced that Kate-like sessions in Dolphin would be a
> killer feature. I just read this article: "aseigo: Kate has won"
> (http://aseigo.blogspot.com/2013/11/kate-has-won.html). In that article
> Aaron specifically mentions the Kate sessions feature as critical in his
> decision. 

To be honest, I don't think that comparing Dolphin with Kate makes any sense at all. The main difference between Kate and KWrite is that Kate can open several files at the same time. Moreover, I guess that most, if not all, Kate users (including myself) frequently want to open a certain group of files in one window in certain situations. The "sessions" feature makes this very easy.

On the other hand, saving and opening sessions in a file manager is a feature that probably only a small minority of our users would use. And no, I don't buy the "this is the killer feature that will win new fans for Dolphin" story, sorry.

Let us please stop this off-topic discussion now. It makes reading the bug report for anyone who is interested in the actual logout/login/session restoration bug very painful. If you want to add further info about the "Dolphin sessions" feature, please do it in bug 246028, or maybe even better, talk to usability experts on the kde-usability mailing list and see if they share the "this is the killer feature" opinion.

About the actual bug: the easiest way to approach the problem might be to find out where the session data are stored on logout, and investigate the file after logout (e.g., from one of the text consoles that you can reach with Control+Alt+F1/F2/etc.). The information whether the data are stored correctly or not might help to investigate the problem further.
Comment 11 MountainX 2014-01-21 03:32:12 UTC
The session data appear to be stored here:
file:///home/computeruser/.kde/share/config/session/
In a file named like: dolphin_101a01a[...]4_138s714684_7097437

The data are stored correctly upon logging out. For example, here are the first few lines of that file:

[1]
Active Tab Index=0
Tab 0 Primary Editable=false
Tab 0 Primary URL=file:///home/myuser/Documents//ProgrammingAndCS/Python
Tab 0 Secondary Editable=true
Tab 0 Secondary URL=file:///home/myuser/Workspaces/Python

However, when Dolphin opened up, both sides of the first tab were restored to:
/home/myuser/Workspaces/Python

I checked and in every case, both sides of each tab were restored to the value of the Secondary URL. So that might be a useful clue.

Thanks again and sorry for the passionate plea for the feature. I'll keep future comments focused more narrowly.
Comment 12 Frank Reininghaus 2014-01-21 09:41:39 UTC
(In reply to comment #11)
> [1]
> Active Tab Index=0
> Tab 0 Primary Editable=false
> Tab 0 Primary URL=file:///home/myuser/Documents//ProgrammingAndCS/Python
> Tab 0 Secondary Editable=true
> Tab 0 Secondary URL=file:///home/myuser/Workspaces/Python

This looks OK to me. So it seems that saving works correctly, and re-loading these data is the problem.

One more idea: Have you enabled "Split View" in the "Startup" section of the settings? If yes, does changing it fix the problem?
Comment 13 MountainX 2014-01-22 04:19:28 UTC
(In reply to comment #12)
> One more idea: Have you enabled "Split View" in the "Startup" section of the
> settings? If yes, does changing it fix the problem?

Yes, I have always had "Split View" enabled in the "Startup" section of the settings.

Unchecking "Split View" does in fact "fix" the problem: both the primary and secondary URL are restored properly for each open tab after this change.

I hope this gives you a clue about how to fix the underlying issue so Dolphin works properly with "Split View" enabled . Let me know if you need more information. Thanks!
Comment 14 Frank Reininghaus 2014-01-22 11:24:16 UTC
Created attachment 84797 [details]
Possible fix

Thanks. Knowing a way to reproduce the problem does make debugging easier :-)

It still looked a bit mysterious at first, but adding some debug output helped to find the cause of the problem.
Comment 15 MountainX 2014-01-22 20:25:13 UTC
(In reply to comment #14)
> Created attachment 84797 [details]
> Possible fix
> 
> Thanks. Knowing a way to reproduce the problem does make debugging easier :-)
> 
> It still looked a bit mysterious at first, but adding some debug output
> helped to find the cause of the problem.

Thank you for the time & work you put into this!
Comment 16 Frank Reininghaus 2014-02-02 09:22:11 UTC
Git commit be29aed516c3088edef136822e1161e7641c33e7 by Frank Reininghaus.
Committed on 02/02/2014 at 09:19.
Pushed by freininghaus into branch 'KDE/4.12'.

Restore the URLs of both views correctly when restoring a session

The problem was that we restored the URL of the right view while the
left one is still active. When we received the signal
urlChanged(KUrl& url) from the right URL navigator, we then set the URL
of the active (i.e., left) view to 'url', such that both views showed
the same URL.
FIXED-IN: 4.12.3
REVIEW: 115406

M  +7    -0    dolphin/src/dolphinmainwindow.cpp

http://commits.kde.org/kde-baseapps/be29aed516c3088edef136822e1161e7641c33e7