The sidebar of Nautilus reduces the width of the content area.
It is obviously annoying at small sizes, and it has been addressed in version 43.
But it can be a trouble at other sizes, particularly when it is useless for the task being accomplished : the common point seeming to be that Nautilus has a medium size because multiple windows are involved : mainly because Nautilus serves as a view of a working folder of documents involved in other applications.
I even recently used 5 windows of Nautilus (one for each of my rating scale) to compare similar photos (same subject shot at different points of view of a trek, so not close in the timeline of my photos manager).
Design proposal
the already existing keyboard shortcut (F9) just needs to be usable without size condition.
Button
It seems that the sidebar has enough space on the left for an extra icon, even for the longest string (gaelic ?) for files :
Or
a Menu entry
like before Nautilus 43 (next to Show Hidden Files)
Bonus
Having the ability to hide the sidebar at every size would also allow to have the same behavior for every size .
I’ve proposed it myself at the time when full-height sidebar layout was adopted, but, after discussing it with designers, I acknowledged a number of problems.
In the collapsed state, there is a conflict between the Show Sidebar and the Go Back buttons, both competing for the priviledged placement at the edge of the toolbar.
Indeed, there is a strongly established pattern for the back button to be positioned right at the start edge of the area if affects (i.e. at the left end of the toolbar in left-to-right locales).
We could place the show sidebar button after the back/forward buttons, but then the button would change position when showing the sidebar, which breaks the whole idea of it working as a toggle.
When the sidebar is shown (which is the regular mode), the pressed sidebar button, having a dark background, attracts more visual attention than it warrants.
Also, the top left corner window itself is a very prominent placement, and it would be a waste not to use it for a more essential feature. The current design plan is to have a (global) search button there. So, this proposal is in collision course with the design plans.
a Menu entry like before Nautilus 43 (next to Show Hidden Files)
The menu is in the sidebar now. So, if you hide the sidebar, there is no menu to show it again.
Concerning the button design, I did it this way only because there is a button located at this place on the small window design, but that is not my preferred design.
I don’t think switching the view of the sidebar needs a button just for it as it’s not a frequent need.
My workflow just use the keyboard shortcut, so I personally prefer a menu entry (like in most of the others file browsers, by the way).
If I may, I don’t think moving the menu to the sidebar was a great idea, as it demands more actions to access all the commands in it in the small size windows : I’m guessing it was decided (as a compromise) to gain room in small sizes to have an icon to improve discoverability of the way to switch on the sidebar, but as I said before, I don’t think switching the view of the sidebar needs a button just for it. Therefore removing this button would leave space for returning the menu where it was (with an entry to switch the sidebar ).
The problem would then move to find another way to help the user to find how to switch on the sidebar on small windows…
This would be really helpful for my most common use case (2 nautilus windows tiled horizontally aka split view).
As a stop-gap in the meantime, while design decisions are made, I patched my local nautilus to limit the sidebar at its minimum width on any medium/large screen size, and ignore the width expansion caused by AdwBreakpoint. It still collapses when the window is very small, which is great for other folks’ use cases.
This added screen real estate really helps in list view with long filenames. And the sidebar just looks better aesthetically IMO without all the unused space at it’s currently implemented full width.
.
).