GNOME Bugzilla – Bug 135118
reproduceable way to open multiple spatial windows of the same folder
Last modified: 2006-10-18 15:25:31 UTC
Description of Problem: I found a method to open multiple views of the same folder in spatial mode. Steps to reproduce the problem: 1. Create a link to /home on the Desktop 2. Navigate to /home in spatial mode using the 'Computer' icon on the Desktop 3. Open /home link on Desktop Actual Results: Clicking the /home link opens up another spatial mode view of the /home folder. Expected Results: It should just raise the exisiting /home view to the top of the z-order. How often does this happen? Everytime Additional Information: Latest garnome 0.30.1 with nautilus version 2.5.7
Messes up spatial mode so setting TARGET2.6.0. I can reproduce this.
Well. We changed the way symlinks to directories are handled so that they are more like real directories. This means /mnt/hdb2 and /opt/gnome -> /mnt/hdb2 are considered two locations. This really isn't a bug, but something we've chosed to do. In the future we will work on adding better UI to set up desktop symlinks as "shortcut style" links.
*** Bug 141602 has been marked as a duplicate of this bug. ***
*** Bug 138975 has been marked as a duplicate of this bug. ***
Please reconsider if it's necessary to have special "desktop shorcuts". I think it's not. What would be IMHO reasonable is to not expand symlinks for purpose of parent hierarchy and invoking external apps on files from the directory but expand symlinks otherwise. The directory opened through the symlink or not IS NOT a different object.
*** Bug 143840 has been marked as a duplicate of this bug. ***
This needs to be reconsidered. The current behavior is contrary to a UI principle underpinning spatial mode; specifically, the same location in the directory structure should appear consistently in a window that is, at least superficially, the same. Symlinks don't create new locations; they create additional paths to the *same* location.
*** Bug 149216 has been marked as a duplicate of this bug. ***
*** Bug 144919 has been marked as a duplicate of this bug. ***
Who chose, and why? I think if an otherwise spatial system breaks the metaphor on purpose, we'd at least like to know why. (Remember, a broken metaphor is worse than no metaphor.) In bug 144919 I've listed 4 rather bizarre symptoms of this. I can't understand how the current behavior would be anything but confusing. (I don't create links with Nautilus any more, because it's just too easy to break them.) In addition, even if you don't (for whatever reason) buy that breaking the spatial metaphor is inherently bad, it's (a) different from how the Mac's spatial worked, and (b) apparently it's different from how lots of actual people think it should work -- note all the dupes. People are expecting "1 folder = 1 window", and getting bitten by it in 6 different ways, and that's only counting the people with enough tenacity to actually file a report. Please reconsider, or (at the very least) explain. If it's confusing a lot of people, it needs to be either fixed or documented.
Created attachment 33748 [details] [review] Fix Nautilus symlink behavior Here's a quick little patch to fix this bug. It's a patch for 2.6.3, but it looks like the latest version is similar enough it should still apply OK. Problems with this patch: - doesn't use GNOME_VFS_FILE_INFO_SYMLINK() (I couldn't get it to work, so I just check ->symlink_name for NULL) - not sure where this code belongs -- maybe it should be in nautilus-application.c, at the start of nautilus_application_present_spatial_window() - if I double-click a link and then alt-up twice, it sometimes (but not always) closes the middle folder; not sure why
*** Bug 318951 has been marked as a duplicate of this bug. ***
This needs to be reconsidered. There's a patch, and a ton of duplicates. The current situation is a mess. As writer of the User Guide, and therefore *responsible* for having to explain this mess to users, I'm reopening.
Joining the angry mob with pitchforks here. While I can agree that links should be treated the same way they are in the command line (IE: the link and the target are entirely different), this messes things up when these same links are created in nautilus. If I, as a user create a link in nautilus (and remember that link and shortcut is probably the same word in many languages), I would expect it to be a "nautilus link", not a command line link. A nautilus link should remember all properties of the nautilus window. Another option would perhaps be to show the path of the LINK in the path bar and similar places, but to inherit all of the options so that everything looks the same. This would be the closest to the way the command line handles this.
Martin, Alexander, Christian: This needs to be reconsidered. There's a patch, and a ton of duplicates. This is a mess to users. Please DO take a look at this for 2.16.x, make many users and the gnome documentation team a bit more happy. Thanks in advance.
We've already switched this back and forward multiple times before. Each time we get a host of angry users with pitchforks that didn't like the new way. The current decision isn't really finished as we don't have nice support for creating shortcuts yet. But, we're not just flipping this again.
So it's not really a WONTFIX, but a WONTFIXYET?