KFileDialog: "Parent Folder" button

[Peter Penz]

Am Wednesday, 30. July 2008 17:55:35 schrieb Aurélien Gâteau:
> Peter Penz wrote:
>  > I played around having a button to reveal the hidden part of the
>  > URL, as this was also my preferred solution. But it did not work as
>  > well as I expected it:
>  >
>  > * The icon is one minor but tricky problem. I tried using a '<'
>  > arrow, but then the URL looks like this '< Pictures > 2008 >
>  > January'. It's not obvious that '<' reveals the hidden parts.
>
> Yes I understand. Maybe using "..." as a text would look better?

"..." is already used if the current URL does not fit into the available 
horizontal space. But yes: I think finding an icon which at least indicates a 
difference to '>' should be possible.

>  > * The reveal-hidden-part-button is no solution to the problem when
>  > being in the editable state of the URL navigator. By having an
>  > up-button this issue is solved too in a nice way.
>
> Yes, up-button is the way to go for editable state.

:-)

>  > * I did no tests with other users yet, but in my personal usecases I
>  > really just wanted to go up one hierarchy (e. g. from my
>  > home-directory to /home to visit another user). With the up-button I
>  > just click the button once, by having the reveal-hidden-part-button
>  > two clicks are required (and for the second click I need to move the
>  > mouse to hit the correct folder).
>
> Two click would not be required if we went "the Gtk+ way". And the
> user would get instant feedback as to were he is. No more need to
> click the button to get this information.

Hm, I don't get this: From my point of view the problem is not about finding 
out where the user is. The whole idea of the URL navigator is based on using 
bookmarks as shortcuts to long paths (see e. g. 
http://dolphin.kde.org/features.html). So the user uses bookmarks as shortcuts 
to prevent having URLs like "home/peter/Documents/Pictures" and replace them 
by e. g. just "Pictures". So "home/peter/Documents/Pictures/2008/January" will 
presented as "Pictures > 2008 > January".

It's a similar concept like in internet-browsers :-) If you've set a bookmark 
"KDE4 Build Howto" you don't care that the real URL is 
"http://techbase.kde.org/Getting_Started/Build/Unstable_Version".

That was also the reason that the URL navigator initially had no up 
functionality at all, as it is always possible to select the bookmarks and go 
to the desired path from there. Beside this it is also possible adding a "Go 
Up" button to the toolbar anyhow.

So to get back to the point: if the user wants just to know the original path 
behind the breadcrumb ("finding out where he is"), then clicking on the 
editable state gives him the most accurate information already by one click.

So the Gtk+ way still needs two clicks + moving the mouse just for getting up 
to a parent folder.

The basic question for me is: What's the benefit of having the "Gtk+ way" in 
comparison to the "go-up" button? Maybe I'm really missing something here, but 
currently I fail to see the benefit.

> The current behavior is also a bit surprising I think. If I am in a my
> "Gwenview" bookmark which points to "~/kdesvn/kdegraphics/gwenview", the
> widget looks like this:
>
> [Up][Gwenview]
>
> when I click on the Up button, I get this:
>
> [Up][Home][kdegraphics]
>
> I think it looks a bit surprising to get a "longer" url when I click Up.
> Difficult to explain with words, just a feeling.

I think what you want is an URL navigator that does not hide parent paths but 
just a way to click on "path-breadcrumbs"... I thought about having this as 
option, but honestly speaking I'm against having a third mode for this. For me 
the key feature of the breadcrumb is not that clicking on directories is 
possible, but to hide parent paths.

For users who like the "pure truth" the editable mode is available to have a 
presentation that has been used during the last 10 years of KDE ;-)

>  > So I'm not sure whether the reveal-hidden-part button is  really
>  > better. I'll blog about this issue during the next week, maybe the
>  > feedback gives a rough indication about the preferred approach :-)
>
> Good idea.

Well let's see what the blog entry might bring as input :-)

> Aurélien

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