It is useful to have convenient access to hard drive partitions via the sidebar in Files and file pickers.
GNOME/GTK currently does a good job in keeping the sidebar clean by limiting the partitions/volumes that are displayed in the sidebar. It tends to show eject-able/external drives in the sidebar while relegating internal volumes to the “Other Locations” view.
It is currently possible to bookmark the mounted directory of a partition as one would bookmark a regular directory. However this method is not very usable as the bookmark is no longer useful once the volume is unmounted, for example after a reboot. Also, the bookmarked mount point directory name shown in the sidebar is usually not user-friendly as it is usually named after the UUID of the volume.
Wouldn’t it be beneficial to allow the user the choose partitions/volumes to be pinned/added as bookmarks to the sidebar. Basically the user could by allowed to pin a volume to the sidebar via a right-click/context menu for the volumes that are currently shown in the “Other Locations” view. Once pinned/bookmarked, they would behave exactly like the ones that are shown in the sidebar by default. Activating a pinned volume would automatically mount the volume if it’s not currently mounted.
I am currently adding the pinned volumes to the existing bookmarks file by using an artificial URI scheme: “volume:///” followed by the UUID of the volume. We may very well use a dedicated bookmarks file exclusively for volumes just like we have one for bookmarked network locations.
Screenshots of the file-picker dialog built from my modified GTK code are attached.
Nautilus can do what it wants. It has its own copy of the sidebar. Sharing it, and striving to make the file chooser a clone of nautilus, was a mistake from the beginning.
Thanks @sachindaluja for igniting the discussion and providing a prototype!
I support the idea of allowing the user to pin internal drives to the sidebar. This was originally planned, but has unfortunately never been implemented until now, so I’m very glad you have picked interest in making it happen!
Back then, the plan was to simply hide the internal drives/partitions (including the system root “/”) from the sidebar by default, giving the user an option in the Disks app to make them visible in Files.
This is currently a “Show in user interface” checkbox, within “Mount Options”. This needs to be changed to a “Show in Files” option that is in the top level of the partition menu.
Second design: Add Drive dialog
The next iteration is documented in Allan’s blog post. Instead of going to the Disks app, the user would be able to add internal drives to the sidebar using a new dialog:
To achieve this, we want to make adding drives to the sidebar a manual action. In this way you will be able to customise the sidebar to your needs.
Third design: + Other Locations
When the implementation began in 2015, the “Add Drive” dialog was transformed into the “Other Locations” view. However, manually adding drives to the sidebar was still part of the design:
It should be possible to add /, internal volumes, and network locations to the sidebar by bookmarking them.
This part of the design hasn’t been implemented at the time.
I think that the “Other Locations” approach is better than the dialog. But the name “Other Locations” was always a bit confusing and misleading for a normal Desktop user.
Thanks for the feedback, Matthias. I’ve been unsure about what the plan should be for nautilus moving into GTK 4. May I ask for more clarification and setting expectations?
At the moment nautilus is still GTK 3, so it actually uses the public GtkPlacesSidebar. So, bug fixes and enhancements patches go to GTK.
After porting nautilus to GTK 4, where GtkPlacesSidebar is no longer public, I’ve been assuming nautilus would keep a copy of it in-tree, but keeping it in sync with GTK (just like it already does for GtkPlacesView).
However, what to expect for the GtkPlacesSidebar/GtkPlacesView design going forward? Is the current design to remain frozen forever? Would the nautilus copy need to diverge for any small enhancement, or would they be considered case by case?
The original intent was keeping the design of the file selection dialog in sync with Nautilus. This has proven to be a mistake: file selection and file management are two fundamentally different operations; this is especially true when file management happens in a modal dialog attached to another application.
In general, we expect the file selection dialog to be simpler than the file manager; we also expect the design of the file manager to be iterated faster than the core toolkit. Any change in Nautilus or GtkFileChooserWidget will have to be evaluated separately, and we will decide on a case by case basis what kind of behaviours should be applied to both.
