Re: Proposal for bug 73937 / symlinks in nautilus

[Alexander Larsson <alexl redhat com>]

On 11 Jan 2003, Ettore Perazzoli wrote:

> On Tue, 2003-01-07 at 10:30, Alexander Larsson wrote:
> > > http://bugzilla.gnome.org/show_bug.cgi?id=73937
> > > 
> > > It fixes the problem of resolving the real path of symlinks in nautilus.
> > > The bug is, if you change to a dir which is a symlink i.e.
> > > /pub->/misc/pub and click the dir up button you end up in /misc and not
> > > /.
> > > 
> > > I think.....see the bug report what other people think about that.
> > > 
> > > The patch contains no change log entry.....be patient with me I'm a
> > > newbie volunteer, who need to be educated by you.
> > > 
> > > Would be nice if I could get some feedback.
> > > (I know you all are busy hunting "the big bugs")
> > 
> > I agree with the reasoning that we should do it the unix-way, so I'm 
> > changing this.
> 
> I would hesitate to change the behavior of the application like this
> when there is no strong evidence that the new way would actually be any
> better for the majority of the users; especially when a bug doesn't have
> any duplicates like this one.  Maybe some user testing would be in
> order?..  (And shouldn't this change be discussed with the usability
> team at least?)

I agree that it might need more discussion.
 
> And in fact, I don't agree with this change.  The only reason that is
> given on Bugzilla is that the old behavior is different from that of a
> command-line shell, but if Nautilus is really supposed to imitate the
> usability of a command-line shell, then we are all doomed.  :-)
> 
> First of all, this makes the notion of a location in Nautilus much more
> complicated to understand.  Before, "/folder1/folder2/folder3" meant
> that you were in folder3 which is contained in folder2 which is
> contained in folder1.  folder2 was never a link; so it was obvious what
> the physical hierarchy of the directory structure on the disk was.  Now
> instead, "/folder1/folder2/folder3" could mean any sort of things
> depending on which of these folders are actually links.  IMHO while
> links are difficult to understand already, this makes them even more
> difficult to grok.  (Besides, this is not how the other systems (MacOS
> and Windows) work.)

Thats not entierly true. Only "activation" of a particular symlink ever 
resolved it. There were multiple ways to get to a location where one of 
the parent dirs is a symlink:
a) Type it in the location bar
b) follow a symlink to something that has a symlink in the path
c) follow a desktop link, bookmark or whatever to the path with a symlink
d) start in /home/username and /home is a symlink

The problem with resolving symlinks on activation is that it conflicts 
with how unix system typically use symlinks to hide implementation 
details. For instance, my /tmp is a symlink to /mnt/hdb2/tmp, but I want 
users of my system to not have to care about this and just think of /tmp 
as a normal dir. This is what symlinks do, they allow you to design your 
filesystem in a virtual way to be as you want.

I would argue that a more transparent handling of symlinks (e.g. not 
resolving them to their implementation path) is easier for users to 
understand, since they don't need to care about the concept of symlinks at 
all. "They are just normal directories."

If you really need shortcuts the way windows does them we have desktop 
file links that do exactly this.
 
> Also, in the old way the meaning of the up arrow button was very clear:
> "bring me to the folder that contains this folder".  And it was
> consistent too: once you had a certain folder displayed, no matter how
> you got there, hitting the up arrow you would always give you the same
> result.  Now, it becomes all complicated because the expected result of
> clicking the up arrow button depends on the history of how you got
> there-- which it didn't before.

I would argue that symlinks are very seldom used to make two paths that 
you ise regulary the same. Instead they are typically used to "clean up" 
the path to something and make it apear in a logical hierarchy.

This means that the user almost always (especially novice users) believe 
that the symlink path is *the* location, and are not suprised when "up" in 
/tmp goes to / instead of /mnt/hdb2. Instead I think they would be 
confused if following "tmp" in / would go to /mnt/hdb2/tmp as this would 
unnecessary expose them to the concept of symlinks which they would be 
forced to learn.
 
> So the sum is, changing the behavior in the proposed way would make both
> the location bar and the "up arrow" button harder to understand without
> adding any usability benefit.  

I disagree, although my reasoning depends on the fact that users don't 
typically create dir1 and symlink -> dir1 and regularly want to use 
both of them. This may be a wrong assumtion though.

I also argue that the old behaviour wasn't really consistent, which made 
the user model quite hard to understand.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a hate-fuelled white trash ex-con on the run. She's a disco-crazy 
communist bodyguard married to the Mob. They fight crime!