Bug 315471 - Using Alt+Up to go up a level in Dolphin highlights wrong folder
Summary: Using Alt+Up to go up a level in Dolphin highlights wrong folder
Status: RESOLVED NOT A BUG
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 2.2
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
: 335306 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-19 20:09 UTC by BasioMeusPuga
Modified: 2017-08-20 23:47 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description BasioMeusPuga 2013-02-19 20:09:10 UTC
Alt+Up takes you up a level in dolphin. However, this ends up selecting the first folder in the parent instead of the folder you just came from.

Reproducible: Always

Steps to Reproduce:
1. Run Dolphin
2. Go into a folder
3. Press Alt+Up to return to parent folder
Actual Results:  
The first folder is selected by default.

Expected Results:  
Selected the folder I entered.

Alt+Left has behaviour similar to what I'd expect. However, that is the equivalent of "cd -" instead of "cd .."

So, bug or feature?
Comment 1 Frank Reininghaus 2013-02-19 21:26:30 UTC
Thanks for the bug report, but I'm afraid your expectation is wrong.

There is no reason why the state of the view (i.e., selection, scroll position, current item, etc.) should depend on the history if you did not go "Back". See, e.g., the discussion in bug 193549.
Comment 2 BasioMeusPuga 2013-02-20 16:34:34 UTC
Hey,

Thanks for taking the time to reply. And I'll not be a nag about it. However, just bear with me for a moment here:

If you jump to a folder from $HOME e.g. /usr/share/, pressing Alt+Up will take you to /usr/ and select /usr/bin/. Now if I wish to go back to /usr/share, I'll have to press the right arrow 5-6 times or play the typing game.
In this case, pressing Alt+Back will take you back to $HOME. Definitely the wrong direction.

I understand that this is a design decision, but if you'd average it out, going back to the folder you just came from (and having Dolphin remember scroll position) seems, IMHO, more intuitive than resorting to different key combinations. Especially so in folders with large numbers of items.

Also, all other file manager I've tried (thunar, nautilus, krusader, pcmanfm and even Windows Explorer / Finder) implement this behavior as I've described above with the same (Alt+Up) key combination.

I went through the other bug report and I guess I'm in the same boat as Gene in the end. "Probably not a big deal".

Again, thanks for taking the time.
Comment 3 Frank Reininghaus 2013-02-21 09:13:29 UTC
I did bear with you for a moment and read your comment a couple of times, but I don't understand the use case you describe.

1. "jump to a folder from $HOME e.g. /usr/share/": OK, I'm first in ~, and then I enter /usr/share in the location bar.

2. "pressing Alt+Up will take you to /usr/ and select /usr/bin/": Agreed.

3. "Now if I wish to go back to /usr/share, I'll have to press the right arrow 5-6 times or play the typing game.": OK, so I assume that you want to select /usr/share while viewing the contents of /usr. I see that this requires a few key presses.

4. "In this case, pressing Alt+Back will take you back to $HOME. Definitely the wrong direction.": Hm, but if we are still in /usr, and we were before in /usr/share, why would take "Back" take us to $HOME?

I tried to figure out ways to modify one of the steps in your description such that the last step ("wrong direction") makes sense for me, but I failed :-(
Comment 4 BasioMeusPuga 2013-02-23 07:06:19 UTC
I meant pressing Alt+Back from the directory you first jumped to (using the location bar). I guess the order came out wrong. In hindsight, I realize mentioning this seems redundant.

Regardless, I hope I made a better point with the rest of the argument vis-à-vis intuitiveness and shifting from another file browser.
Comment 5 Frank Reininghaus 2014-05-25 09:00:51 UTC
*** Bug 335306 has been marked as a duplicate of this bug. ***