Bug 193549

Dolphin remembers the folder scroll positions since KDE 4.0. Could you please give more informations how to reproduce the bug (used view mode, number of items, ...)? Thanks!

I'm sorry, this is a Konqueror issue, not a Dolphin issue. I switch between the two often and got confused.

Konqueror 4.2.2 (KDE 4.2.3) does not remember scroll positions in the Detailed nor Icon views, possible in other views as well.

Kfm 4.2.2 in detailed view does not remember the scroll position and pops back to the top of the directory/file list. However, Dolphin does keep the position when you go back but it leaves it unmarked (but at least it doesn't pop to the top). To be truly useful, a mark of where you previously were is needed. Kfm in KDE 3.5.x used a dotted outline around the filename or directory name you just came out of. Nautilus highlights it (but only when you go "up").  Dolphin and the new konqueror file manager for kde 4.2.x should keep and mark the scroll postion.

To me, this was a great feature in kfm 3.5.x. I really miss it in kde 4.2.x.

I originally reported this in bug 193076 but didn't mention Dolphin.

I see this has not been fixed in 4.2.3 or 4.2.4. As a note, it does work correctly in krusader (but don't care for the always double display and the way drag-drop copies into directories instead of beside them).

To restate the problem:
kfm/konqueor pops back to the top when backing out of a directory and does not mark with dotted outline the directory that was previously gone into.

dolphin does not pop back to the top but still does not mark with dotted outline the directory that was previous gone into. It least it always keeps the previous directory in view.

still not fixed in 4.3.0

*** Bug 193076 has been marked as a duplicate of this bug. ***

SVN commit 1049164 by freininghaus:

When navigating back/forward in the DolphinPart inside Konqueror, remember

1. the current item,
2. the scroll position of the view, and
3. the expansion state of the details view.

Before 3. can be implemented in Dolphin itself, some changes in
KUrlNavigator are required.

This fix will be in KDE 4.4.

BUG: 193549
BUG: 198073
BUG: 213137


 M  +1 -0      CMakeLists.txt  
 M  +46 -0     dolphindetailsview.cpp  
 M  +27 -0     dolphindetailsview.h  
 A             dolphindetailsviewexpander.cpp   [License: GPL (v2+)]
 A             dolphindetailsviewexpander.h   [License: GPL (v2+)]
 M  +12 -0     dolphinpart.cpp  
 M  +3 -0      dolphinpart.h  
 M  +129 -13   dolphinview.cpp  
 M  +35 -0     dolphinview.h  
 M  +4 -9      dolphinviewcontainer.cpp  
 M  +0 -6      dolphinviewcontainer.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1049164

This is almost fixed in 4.3.95 (4.4 rc2) in konqueror. However, it fails to remember the position when going UP. Ok going BACK. This worked correctly in both respects in 3.5.x KDE.

This may be only partially related, right click on UP does not just go up but requires you to also select the level to go up to. Should just go up one level with no explicit selection.

> right click on UP does not just go up but requires you
> to also select the level to go up to. Should just go up
> one level with no explicit selection.

That sounds like expected behaviour. Left click on Up goes up one directory, right click lets the user choose how many directories.

@Gene: Dotan is right, going "Up" should not restore the position, as going up adds a new entry in the history, which can be iterated again by "Go Back"/"Go Forward".

(In reply to comment #10)
> @Gene: Dotan is right, going "Up" should not restore the position, as going up
> adds a new entry in the history, which can be iterated again by "Go Back"/"Go
> Forward".

I see what you are saying, kind of, but looking a Nautilus, it seems to preserve the position on when you go UP or back. So did old konqueror from 3.5.x days. But probably not a big deal.

The point I was trying to make about "right clicking on UP" was phrased wrong. What I mean was if you open a context menu by right clicking and choosing UP from the list then you have to make another choice as to how far UP to go. I think that if you simply click the UP line without making an explicit choice, it should default to the first choice (which is the same as if you had pressed alt-up shortcut, up on level). The current UP context menu requires at least 2 mouse operations to go up one level. (But it is good that you have the choice to go up more than one level if you want.)