GNOME Bugzilla – Bug 122381
Add an option to NOT show root filesystem in the sidebar tree
Last modified: 2012-07-20 12:04:01 UTC
It'd be nice to have an option to disable browsing the root filesystem in the tree, so that only $HOME can be browsed. Browsing outside $HOME is useless for me and probably confusing for non-experienced users who will get all sorts of write errors when trying to write to /usr/lib or will be confused when browsing /dev.
I'd like to second this motion and extend it a bit as well. The "Filesystem" root should go away and be replaced by a few other roots like one for the other user's home directories and another for /tmp, that way the users won't be confused with such things as "/bin", "/boot", "/initrd", "/mnt", "/proc", etc. I know what's inside each of those things but would never use nautilus to access them.
At the time when you wrote this bug report, was the tree view already multi-rooted, i.e. did it contain both the home folder and the filesystem as toplevel nodes? Are you O.K. with the current solution, where we display $HOME, / and all mounted volumes as toplevel nodes?
I'd like to have an option to turn the / node off completely, browsing the root filesystem with nautilus is a silly thing to do IMHO. I don't think it matters that much now that nautilus is spatial anyway. Maybe the /dev, /proc, /lib etc issue could be solved by having some kind of mechanism for hiding contents of these dirs like Windows does with 'Program Files' and 'Windows' dir, show a message saying 'these are system files so be careful' and a button to explicitly make the contents visible if you know what you're doing. Thanks
IMHO this option should not vanish entirely. Point is, there are totally valid reasons a user might want to navigate his tree, at least occasionally. Think of large data mount points, or mounts of remote file systems being available by the system without the need for the user to manually create it locally in the first place. Things like /data and /vdr come to mind, as well as autofs mount point available to any user. It would suck pretty badly, if the user needs the help of his/her geel friend who set up the /vdr "thingy" just to wathc a movie. "That's a user friendly system, when I am not able to find that data and need help..." The multi-rooted tree is just about right, IMHO.
I'm a pretty advanced user and I never use the "Filesystem" root in Nautilus. All my volumes are mounted and get a root in it. Home and Desktop are all I need besides that. Maybe a root for /tmp would be useful as well. I would just leave it in the Computer folder. Even that could be taken out since you can always do "Open Location"->"/"
Info provided, reopening.
Created attachment 160349 [details] [review] conceal root gconf key Here's a patch I whipped up. It adds the gconf key preferences/conceal_root, defaulted to false. Root will still be exposed via 'Open Location (Ctrl+L)' or the Computer location. But, your home directory and mounts will appear as toplevel directories, and the root folder will not show up in the sidebar. Obviously, this isn't a foolproof solution due to the Computer loophole or the fact that GTK+ file dialogs will still expose everything. But it's part of the way.
Review of attachment 160349 [details] [review]: Hi Michael, thanks for the patch. We are thinking too of hiding links to the root file system for 3.0, so this patch is really welcome. I do not have the chance to test the patch as it needs to be ported to GSettings to make it work with Nautilus master. Also, "conceal_root" is a quite obscure name for a preference, I'd rather either a more clear "hide_root_filesystem", or even merge the option with the current "show_hidden_files" preference.
Created attachment 204780 [details] [review] gsettings version Here's a version against current trunk. It uses gsettings and it uses the existing "show_hidden_files" preference to control whether file:/// is shown as a sidebar entry or not.
Review of attachment 204780 [details] [review]: Hey Michael, thanks for the updated patch. Overall, looks pretty good, but I think we should limit this to the actual display of File System entries in the sidebars for now. More detailed comments below. ::: src/nautilus-pathbar.c @@ +1767,3 @@ + parent_file = NULL; /* Pretend file is a top-level root */ + } + I suppose this hides the "back arrow expander" in the pathbar if the button is a fake root (e.g. Home) and the setting is FALSE, right? I'm not really sure it's a good idea to do it, but it should go in another patch, since this is about sidebars. ::: src/nautilus-places-sidebar.c @@ +3415,3 @@ + g_signal_connect_swapped (nautilus_preferences, "changed::" NAUTILUS_PREFERENCES_SHOW_HIDDEN_FILES, + G_CALLBACK(show_hidden_changed_callback), Missing space after G_CALLBACK ::: src/nautilus-tree-sidebar.c @@ +1462,3 @@ + else if (!g_settings_get_boolean (nautilus_preferences, NAUTILUS_PREFERENCES_SHOW_HIDDEN_FILES)) { + fm_tree_model_remove_root_uri (view->details->child_model, "file:///"); + } I think the logic here is not optimal; shouldn't it be more something like (pseudo-code)? has_root = fm_tree_model_get_iter(root_file) && fm_tree_model_is_root(root_iter); show_root = g_settings_get_boolean(show-hidden-files); if (show_root && !has_root) fm_tree_model_add_root_uri(); else if (!show_root && has_root) fm_tree_model_remove_root_uri(); ::: src/nautilus-window-manage-views.c @@ +315,3 @@ + !g_settings_get_boolean (nautilus_preferences, NAUTILUS_PREFERENCES_SHOW_HIDDEN_FILES) && + is_fake_root (slot->location)) + allowed = FALSE; I am not sure we want to block the Up action according to the setting this way. The setting is about showing "hidden files" in the UI, not about locking access to directories going up fake roots. At least, it should go into a separate patch, but I would like to discuss this with designers first. ::: src/nautilus-window-pane.c @@ +695,3 @@ + "changed::" NAUTILUS_PREFERENCES_SHOW_HIDDEN_FILES, + G_CALLBACK(show_hidden_changed_callback), + window); Wouldn't this belong to NautilusWindow instead?
This bug should no longer be present with the latest Nautilus redesign.