Pin volumes/partitions to sidebar in Files (nautilus) and file pickers

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 have a few patches that I developed for the current GTK(4) master branch to demonstrate the UI and the implementation details:

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.


Here is what I said on irc:

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.

1 Like

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!

Historical background

First design: option in Disks

The last sidebar redesign began in July 2013, with @allanday’s whiteboard wiki page (following my modest proposal).

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?

1 Like

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.


Thanks, we are on the same page now.

So, after porting to GTK 4, we can start working on sidebar enhacements directly in nautilus, and maybe propose the same changes for GTK.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.