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 702543 - give a visual clue under which 'root' the current folder is
give a visual clue under which 'root' the current folder is
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: Navigation
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-06-18 10:27 UTC by Luc Pi
Modified: 2021-06-18 15:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Luc Pi 2013-06-18 10:27:24 UTC
Give a visual clue under which root the current folder is.

A nautilus window shows the content of a folder. This folder is either on my system, one drive or another; maybe one a remote drive; or a usb one. It might be a disc but also a camera, etc.

Nautilus should give a clue where this folder comes from (basically under which 'root' it is). The root could be a physical drive, but also a partition or just a folder. We used to be able to change the window background color. Now they all look the same.
Comment 1 António Fernandes 2013-06-18 10:36:38 UTC
The root is supposed to be shown in the leftmost button of the path bar. Is this not working?
Comment 2 Luc Pi 2013-06-18 11:50:32 UTC
(In reply to comment #1)
> The root is supposed to be shown in the leftmost button of the path bar. Is
> this not working?

as soon as I go down a few folders the device button disappear.

and this is only limited to devices.

as an example, I have a STUDIO folder with my graphical works. I used to have a different bg color for this folder and all its children.
Comment 3 António Fernandes 2013-06-18 12:25:23 UTC
(In reply to comment #2) 
> as soon as I go down a few folders the device button disappear.

Oh, right, path bar overflow is a problem. This can be fixed by always showing the root and collapsing the next buttons, like this:

[root][…][foo][bar]

This idea has been proposed in an old design whiteboard: https://live.gnome.org/Design/Whiteboards/Breadcrumbs

> and this is only limited to devices.
> 
> as an example, I have a STUDIO folder with my graphical works. I used to have a
> different bg color for this folder and all its children.

I don't understand how this is related to this bug. Is your STUDIO folder a bind mount of to the root of another partition?
Comment 4 Luc Pi 2013-06-18 12:57:52 UTC
(In reply to comment #3)
> (In reply to comment #2) 
> > as soon as I go down a few folders the device button disappear.
> 
> Oh, right, path bar overflow is a problem. This can be fixed by always showing
> the root and collapsing the next buttons, like this:
> 
> [root][…][foo][bar]
> 
> This idea has been proposed in an old design whiteboard:
> https://live.gnome.org/Design/Whiteboards/Breadcrumbs

yes


> > and this is only limited to devices.
> > 
> > as an example, I have a STUDIO folder with my graphical works. I used to have a
> > different bg color for this folder and all its children.
> 
> I don't understand how this is related to this bug. Is your STUDIO folder a
> bind mount of to the root of another partition?

I am using 'root' in a large meaning: "The root could be a physical drive, but also a partition or just a folder".

The user could tell "from here and below, it is a special tree, I want to distinguish from the others". Rather than only devices and mount points, which is more technical than semantical.


As another practical example, you could have several project folders, which tree looks pretty much the same. Having a visual clue "I am in project B" helps, rather than knowing that "I am in Home".

Or in general, "OK, I am in Home, but more interestingly, I am in subtree XYZ".

This is what we do in real life by organizing files into folders, boxes and shelves.



Background colors worked well for these use cases, unless that it had to be set by hand, or recursively by a command, and it had to be updated at each new folder creation.
Comment 5 Luc Pi 2013-06-24 08:57:27 UTC
Bug 702948 could be a solution for this one
Comment 6 André Klapper 2021-06-18 15:30:20 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.