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 different. 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 wrong. -- Ettore
Attachment:
signature.asc
Description: This is a digitally signed message part