After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 135118 - reproduceable way to open multiple spatial windows of the same folder
reproduceable way to open multiple spatial windows of the same folder
Status: RESOLVED WONTFIX
Product: nautilus
Classification: Core
Component: general
2.14.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 138975 141602 143840 144919 149216 318951 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-02-22 14:14 UTC by Richard Ferguson
Modified: 2006-10-18 15:25 UTC
See Also:
GNOME target: 2.16.x
GNOME version: ---


Attachments
Fix Nautilus symlink behavior (1.83 KB, patch)
2004-11-14 02:39 UTC, Ken Harris
none Details | Review

Description Richard Ferguson 2004-02-22 14:14:52 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
Comment 1 Matthew Gatto 2004-02-23 01:22:23 UTC
Messes up spatial mode so setting TARGET2.6.0. I can reproduce this.
Comment 2 Alexander Larsson 2004-03-02 09:21:39 UTC
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.
Comment 3 Tim Herold 2004-05-09 05:46:03 UTC
*** Bug 141602 has been marked as a duplicate of this bug. ***
Comment 4 Tim Herold 2004-05-09 05:48:32 UTC
*** Bug 138975 has been marked as a duplicate of this bug. ***
Comment 5 Tomas Mraz 2004-05-09 07:02:48 UTC
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.
Comment 6 Tim Herold 2004-06-11 12:14:22 UTC
*** Bug 143840 has been marked as a duplicate of this bug. ***
Comment 7 Braden 2004-06-11 15:12:04 UTC
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.
Comment 8 Vincent Noel 2004-08-03 21:16:15 UTC
*** Bug 149216 has been marked as a duplicate of this bug. ***
Comment 9 Matthew Gatto 2004-10-19 21:19:31 UTC
*** Bug 144919 has been marked as a duplicate of this bug. ***
Comment 10 Ken Harris 2004-11-14 02:30:53 UTC
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.
Comment 11 Ken Harris 2004-11-14 02:39:31 UTC
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
Comment 12 Elijah Newren 2006-01-11 06:08:56 UTC
*** Bug 318951 has been marked as a duplicate of this bug. ***
Comment 13 Joachim Noreiko 2006-03-14 11:43:53 UTC
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.
Comment 14 Sergej Kotliar 2006-04-16 14:47:06 UTC
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.
Comment 15 André Klapper 2006-10-02 09:22:36 UTC
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.
Comment 16 Alexander Larsson 2006-10-18 12:02:08 UTC
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.
Comment 17 Joachim Noreiko 2006-10-18 15:25:31 UTC
So it's not really a WONTFIX, but a WONTFIXYET?