Re: Proposal for bug 73937 / symlinks in nautilus

On Tue, 2003-01-14 at 04:30, Alexander Larsson wrote: 
> > 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
> 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

Yeah, I realized after sending the mail.  :-)

Although, I think in that case it's OK because it's the user who typed
the path in.

> b) follow a symlink to something that has a symlink in the path

Hmm I was not aware of this; maybe the symlink should be fully expanded
before opening the folder it points to as well...

> c) follow a desktop link, bookmark or whatever to the path with a symlink

Same as above?

> d) start in /home/username and /home is a symlink

I am not sure about this one.  In this case maybe making it clear that
you are in the home directory is more important than respecting the
actual physical layout of the folders on the disk.

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

The usage pattern of an end user and that of a Unix sysadmin are

Yes, to a Unix sysadmin, symlinks allow designing of file systems.  But
to a user, symlinks are ways to provide shortcuts to documents and other
things that are in his/her folders.

So, it's true that the user shouldn't care whether /usr is actually a
symlink to /mnt/hda3/usr; but in practice, it doesn't even matter at all
since /usr is not where users put their files.  Actually, users
shouldn't even want to see /usr.

On the other hand, users use shortcuts/symlinks to create bookmarks to
things that they need frequently.  And in that case, the
virtual-path-possibly-containing-shortcuts thing is not only irrelevant,
but also confusing.

> If you really need shortcuts the way windows does them we have desktop 
> file links that do exactly this.

If you really want desktop file links to be used for that purpose, then
using them should be as simple as Windows shortcuts; something difficult
to achieve since desktop file links are much more complicate than a
Windows shortcut.

Besides, desktop file links are not understood by non-GNOME/KDE apps and
are a pain to handle from anything but Nautilus.  So you end up not
using them...

And, really, there is not much difference between a Windows shortcut and
a Unix symlink (while there is quite a difference between a Windows
shortcut and a desktop file link).  On the OS X Finder Unix symlinks
behave like Windows shortcuts, and it just makes sense.

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

I am not convinced at all of this; but anyways, without testing evidence
it's just my opinion vs. yours.  :-)

> 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 think my Desktop link example is a case of that assumption being

-- Ettore

Attachment: signature.asc
Description: This is a digitally signed message part

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