Review Request 123253: dolphin: Navigate to parent folder selects child folder

[Gregor Mi]

> On April 4, 2015, 7:08 p.m., Frank Reininghaus wrote:
> > Sorry if my silence in the bug report was interpreted as agreement. I'm currently traveling and have a bad internet connection.
> > 
> > I think the idea that the bug reporters and the usability team had was the following:
> > 
> > If the user triggers the "up" action, and the parent folder of the current folder was also the previous folder in the history, then "up" should be interpreted as "back".
> > 
> > Such a thing would be straightforward to implement in KUrlNavigator. The new behavior would then be available in all applications that use this class and in the file dialog.
> > 
> > I'm not sure if there is really a need for any more complex "go up" behavior, or if such a behaviour might even be surprising and possibly annoying in some situations. Do you know file managers that do anything more sophisticated than what I described above? Users who do not like the current behaviour have often said that the behavior of Windows Explorer was the reason for their expectations.
> > 
> > Moreover, note that you would have to apply a similar patch to the file dialog (users will expect that its behavior is similar to Dolphin).
> > 
> > Finally, I think that adding a second form of history handling in Dolphin, on top of that in KUrlNavigator, is bad from a maintenance point of view, and might even cause new bugs in some situations.
> > 
> > To sum up, my opinion is that you should modify KUrlNavigator if you want to improve the "go up" user experience. This is very easy, and will cover the vast majority of the troubles that users have reported.
> > 
> > But it's just my opinion, of course. If others, in particular the usability team, have other ideas, then I will shut up ;-)

> Sorry if my silence in the bug report was interpreted as agreement.

Not at all. I am aware that the new behaviour is a bit controversial. But thanks for clearing this. :-) So don't worry and enjoy your travelling.

> If the user triggers the "up" action, and the parent folder of the current folder was also the previous folder in the history, then "up" should be interpreted as "back".

> Such a thing would be straightforward to implement in KUrlNavigator. The new behavior would then be available in all applications that use this class and in the file dialog.

> Moreover, note that you would have to apply a similar patch to the file dialog (users will expect that its behavior is similar to Dolphin).

> Finally, I think that adding a second form of history handling in Dolphin, on top of that in KUrlNavigator, is bad from a maintenance point of view,

Having it implemented in KUrlNavigator is maybe a good tradeoff: a bit less of the feature for a better maintainability. On the other hand, it seemed that when modifying KUrlNavigator it is harder to do everything right to not mess up with the history.

> , or if such a behaviour might even be surprising and possibly annoying in some situations.

I asked some people in my environment (using Windows Explorer) and I can tell they all did not notice the behaviour at all if I hadn't mentioned it. (sure, others might feel different)

> I'm not sure if there is really a need for any more complex "go up" behavior

- I can only speak for myself: after I found it and got used to it I don't want to miss it. E.g. when exploring some hierarchy with keyboard shortcuts it is very handy to always be able to select "the next" folder. By the way, the new behaviour often serves the same purpose as the scroll wheel on KUrlNavigator. But what is "really needed" anyway? :-)
- The reply from the usability team only asks if the _current_ behaviour is still needed somewhere: http://marc.info/?l=kde-usability&m=140273827601672&w=2

> Do you know file managers that do anything more sophisticated than what I described above?

- "Gnome Files" does it as I implemented it here. E.g. entering a location manually triggers the feature.
- ...and "Windows Explorer"... please don't kill me. ;-)


- Gregor


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


On April 4, 2015, 1:17 p.m., Gregor Mi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123253/
> -----------------------------------------------------------
> 
> (Updated April 4, 2015, 1:17 p.m.)
> 
> 
> Review request for Dolphin and Emmanuel Pescosta.
> 
> 
> Repository: dolphin
> 
> 
> Description
> -------
> 
> This is a first working implementation of the feature suggestion filed in the ticket https://bugs.kde.org/show_bug.cgi?id=335616: "Dolphin: Navigate to parent folder selects child folder".
> 
> In short, this is what is does: Whenever the dolphin view is initialized to show the contents of a new URL (e.g. "/home/x/test") it will be checked if the new URL is a parent of the previous displayed URL (e.g. "/home/x/test/documents/aaa"). If the check is successful, then the common child (in this example: "/home/x/test/documents/") folder item will be selected and scrolled into view.
> 
> 
> Diffs
> -----
> 
>   src/dolphinviewcontainer.h 62f91100e9e5d457edd6f4d927c87610335834d7 
>   src/dolphinviewcontainer.cpp 8fea3ba9d0bb8389d89724b9f0cd74605c0286fe 
>   src/tests/kfileitemmodeltest.cpp eba32e1e1caa341e1db26399b4027a86614309fc 
>   src/urlutil.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123253/diff/
> 
> 
> Testing
> -------
> 
> - unit test passes
> - Played around with dolphin: enter URL manually, navigate via click in the item view, navigate via click in kurlnavigator, navigate with Alt+Left, Alt+Right, Alt+up, Backspace
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

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