KFileDialog: "Parent Folder" button
Peter Penz
peter.penz at gmx.at
Wed Jul 30 21:46:28 BST 2008
I'm very sorry for the ugly layout in my previous mail - I switched to KMail
for KDE 4.1 and seem to have enabled "HTML formating" per accident...
Am Wednesday, 30. July 2008 22:41:03 schrieb 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/6813513c/attachment.htm>
More information about the kfm-devel
mailing list