Re: FileChooser's path bar and re-rooting
- From: muppet <scott asofyet org>
- To: Ryan McDougall <ryan mcdougall telusplanet net>
- Cc: Seth Nickell <snickell redhat com>, gtk-devel-list gnome org
- Subject: Re: FileChooser's path bar and re-rooting
- Date: Tue, 16 Mar 2004 00:54:57 -0500
On Tuesday, March 16, 2004, at 12:00 AM, Ryan McDougall wrote:
I think the point is that we should not necessarily halt our progress
wrt UI simply because it breaks some things that were done in the
past. Rather we should ask ourselves whether the way that it was done
in the past is the right way to do it, or if we can do it better in
the future.
Nobody's asking for a halt to UI progress --- we're trying to keep from
throwing out the baby with the bath water.
If you forget a little Unix heritage for a second, and imagine a
possible Unix-based desktop of the near future, what _should_ that use
case you mention be like:
Alice has a file Bob needs, and she wished to make it available to
him. Alice says "the file is at location X", Bob "goes" to X
retrieves the document. Why should X be a Unix path? Could it not be
a URI, or perhaps just a folder in "networks://Folder"? In those two
cases, there is no concept of $HOME.
Yes, if there is no unix path involved, it may make sense for there to
be no "leading noise" in the path bar.
But in a user's home on a local filesystem, it *does* make sense to
have the "leading noise" there, because that information is important.
Just because it's ugly and "archaic" doesn't mean we should hide it
from people. This isn't just about unix paths, the same goes for
c:\Documents and Settings\ and \\fileserver\share\place and
ftp://host/foo ---- we should make the full path to *whatever* *is*
*the* *current* *root* available in the pathbar!
As both i and Joel pointed out, even just having the leading path
information tucked away in the "<" button is sufficient. This would
give the simplicity to the "average user", and full power for the
"advanced user".
Make it easy enough for inexperienced users to use, but do not hinder
their ability to grow into advanced users!
compare
http://asofyet.org/muppet/tmp/subdir-rerooted.png
(the current implementation, with Home rerooted)
and
http://asofyet.org/muppet/tmp/subdir-tucked.png
(the full path available by clicking the "<" button, but tucked away
by default; using the user's name instead of "Home".)
In the first, there is loss of information, but there's no doubting i'm
in a folder under my home directory.
In the second, there is no loss of information, but there's also no
confusing leading path, and since i know my username (i did type it to
log in, after all), i can rather quickly guess that i'm in a folder
under my homedir.
And, in fact, the home dir "shortcut" should be highlighted when it's
active, like this:
http://asofyet.org/muppet/tmp/home-highlighted.png
Notice that i'm not proposing sweeping changes to the UI, or removing
the elegance and flexibility of seth's design --- i'm just saying, take
out the confusing magic, don't pretend that a hierarchical file system
is not a hierarchical file system, and don't treat users like they
can't handle the information in front of them!
When is it okay to re-root? When the root is *actually* different. A
vfs-backended file chooser may have a pathbar containing
[ftp://gtk.org] [pub] [gtk]
A windows machine may have a list of drive letters in the "shortcuts"
list on the left, and the pathbar could contain
[c:] [Documents and Settings] [username] [Desktop] [pictures]
which may be shortened to
[<] [Desktop] [pictures]
But note that the full context of this location, whatever that context
may be, is always available.
--
How come hair colors for women take an hour, but "wash out the gray"
stuff for men only five minutes? This is so unfair!
-- Elysse, complaining about commercials
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]