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 310413 - Pathbar calls homedir 'Desktop' when desktop == home
Pathbar calls homedir 'Desktop' when desktop == home
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: Path Bar
2.11.x
Other All
: Normal trivial
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 313467 314031 316191 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-07-14 20:56 UTC by Reinout van Schouwen
Modified: 2011-03-26 13:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Current situation (38.73 KB, image/png)
2005-07-14 21:50 UTC, Christian Neumair
Details

Description Reinout van Schouwen 2005-07-14 20:56:06 UTC
Distribution/Version: mandriva cooker

If /apps/nautilus/preferences/desktop_is_home_dir is set to true, then the path
bar shows 'Desktop' (this is an untranslatable string, even) instead of the name
of the home directory.

Expected behaviour is to show the name of the home dir instead.
Comment 1 Christian Neumair 2005-07-14 21:40:05 UTC
Fix contained in patch attached to [1]. It changes the pathbar label to "Home",
which is consistent with the file chooser. I'm not sure whether we should change
that in other locations as well. I'll attach a screenshot to illustrate the
issue. Usability crew?

[1] http://mail.gnome.org/archives/nautilus-list/2005-July/msg00196.html
Comment 2 Christian Neumair 2005-07-14 21:50:58 UTC
Created attachment 49190 [details]
Current situation

Note "chris" in the sidepane and in the title and "Home" in the pathbar. Also
note that the button left of "Home" says "home". I've heard that in GTK+ 2.7
the situation is similar wrt the pathbar, i.e. it reads "Home" and is below
/home.
Comment 3 Raphael Slinckx 2005-08-18 13:24:04 UTC
*** Bug 313467 has been marked as a duplicate of this bug. ***
Comment 4 Christian Neumair 2005-08-21 07:45:13 UTC
*** Bug 314031 has been marked as a duplicate of this bug. ***
Comment 5 Christian Neumair 2005-08-21 07:45:59 UTC
Bug 14031 has a similar screenshot (attachment 51026 [details]).
Comment 6 Uno Engborg 2005-08-21 13:33:59 UTC
From a usability perspective, I think we are thinking in the wrong way. Gnome is
trying to map home directories to the file system. This is bound to create
trouble. The problem is that we try to map concepts of unix onto concepts of
everyday life, instead of mapping concepts of everyday life onto unix. 

E.g. When an office user asks a collegue for the sales report of this month, he
will refer to the person who has it, not to the place where that person keeps
it.He will say something like: "Joan, please give me the sales report" not "Top
drawer in the desk of the first office on the first floor, please give me the
sales report."

To get it right, users home directories should probably be something associated
with the full name of the user in the password entries, rather than the place in
the file system. We need something like a "users:/" location to show the home
directories of all users by real names, whith the login id appended withing
parenthesis in case of ambiguity i.e  differentiate between "Joan Smith
(jmith)", "John Smith (jhnsmith)". 

When nautilus displays the users:/ location there should be no up arrow
availabe, just like there is no up arrow available in trash:/. 
Preferrably only users who have been kind enough to set their permissoins to
their home folder so we can read it should be shown in  the users:/ location.

The file browser should remain a file browser, and always show the actual file
system name, regardless if it is /home/jsmith or /home/jsmith/Desktop, and the
pathbar should use these file system names as well. In a desktop environment
users think of the file system like their file cabinet (enforced by the nautilus
file cabinet icon). Artefacts that are conceptually different from things you
normally access by going to your file cabinet should have their own locations
(e.g trash:/ amd my proposed users:/). 

If you go to a location such as my proposed user:/ or to the trash:/ and browse
downwards an up arrow operation should never make you enter anything above that
location. As an example if you put a folder F in your trash and go to the
location trash:/. Then you see the folder F. If you double click F to enter it
your pathbar currently looks like:
[<][Home][.Trash][F]

In my oppinion this is wrong as it breaks the isolation between the file cabinet
and the trash can concept. Instead they should look like
[Trash][F]

My proposed users:/ location should work in a similar way.
Shortcuts could be added to the places menu for "users:/" and
"users:/current user". displayed as Home both in the path bar
and in folder listing of the users:/ folder.
Comment 7 Christian Kirbach 2005-09-01 20:04:32 UTC
adding usability keyword
Comment 8 Daniel Llano 2005-09-17 16:03:59 UTC
I think this bug should be Priority: Normal and Severity: Trivial since there's
no loss of functionality and there are much more important bugs to solve first.
Comment 9 Christian Neumair 2005-09-24 10:29:09 UTC
*** Bug 316191 has been marked as a duplicate of this bug. ***
Comment 10 Christian Neumair 2005-09-24 10:30:52 UTC
Bug 316191 also points out that Nautilus treats the home dir different in the
sidebar, as shown by attachment 52166 [details].
Comment 11 Martin Wehner 2006-12-18 03:40:40 UTC
Lowering priority & severity.
Comment 12 Reinout van Schouwen 2007-08-09 22:54:06 UTC
This seems to work for me now. Anyone else?

By the way, the screenshot from comment #10 was of the GTKFilechooser, not Nautilus.
Comment 13 Jean-François Fortin Tam 2010-01-07 12:49:34 UTC
I don't see this problem in 2.28.
Comment 14 Allan Day 2010-06-20 20:04:29 UTC
Changing component as part of ongoing bug reorganisation work.
Comment 15 Jean-François Fortin Tam 2011-03-26 13:56:24 UTC
This was reportedly fixed circa 2007, confirmed fixed in 2010, and I definitely can't see this bug in 3.0. Note that this is about the pathbar, not the sidebar.