Re: FileChooser's path bar and re-rooting

On Tue, 2004-03-16 at 00:54 -0500, muppet wrote:
> 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.

I was just trying to make a general point, that is sometimes when new
stuff doesn't work right, its occasionally the old stuff that needs to
be fixed. Nothing more, nothing less.

> > 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.

I think that was the point of Seth's future design. What you hide with a
"<" button, he hides in the "shortcuts" bar and calls "context". I think
you you propose is isomorphic to what he proposes.

> Just because it's ugly and "archaic" doesn't mean we should hide it 
> from people.

Actually the definition of archaic does imply that we should hide it.
Not necessarily because its old stuff confusing and "bad", but also so
that we have a platform to migrate away from even doing it in the first
place. So we are not hopelessly attached to previous ideas, like
Microsoft is.

The whole point of the "Alice and Bob Story" is to point out and
question the necessity of Unix pathnames as they exist now. If we don't
rely on Unix path names explicitly throughout the desktop as they exist
now, then its easier to change them to what they should be when we
finally figure you what "should be" is.

> And, in fact, the home dir "shortcut" should be highlighted when it's 
> active, like this:

Once again, I think Seth has said he wants to have just what you

> is not a hierarchical file system, and don't treat users like they 
> can't handle the information in front of them!

I often hear this response ("you treat users as if they are stupid") wrt
changes in GNOME or other UIs. I feel it is a tactic some people use to
try and cow developers into not making changes, since people by and
large dislike change. I'm not accusing you of anything, but I detest
that charge of elitism so much that I had to comment. :)

I personally am not very stupid, but I like the UI changes made in the
chooser and else where. Simplicity does not imply stupidity. I consider
myself a target user for GNOME, and I don't feel the slightest bit
patronized by good UI; and a lot of the new UIs are good.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]