GNOME Bugzilla – Bug 622970
nautilus tabs are stretched over the entire width of the screen
Last modified: 2021-06-18 15:53:03 UTC
As you can see in the screenshot, the previous nautilus version showed neat, evenly wide tabs. The new version stretches them over the entire screen, which is ridiculous when you have only 2 tabs open on a large screen.
Created attachment 164765 [details] screenshot
Yes, I agree with this. * It's inconsistent: Gedit, Epiphany and Empathy all have fixed width tabs (GNOME-Terminal doesn't though - bad GNOME Terminal). Dialog tabs are also have limited widths. * Fixed width tabs don't effectively communicate that the tabs can be reordered. * They don't look like tabs: tabs do attempt to emulate physical tabs in the real world in a loose way. (NB: and they are looking more like physical tabs as time goes on - look at Google Chrome.) The argument in favour of the current approach is, I guess, that a bigger tab is easier to click on. I don't see that as being much of an issue though - they're more than big enough in a fixed width format.
> The argument in favour of the current approach is, > I guess, that a bigger tab is easier to click on Not quite. Here's the commit with an explanation: http://git.gnome.org/browse/nautilus/commit/?id=fb39afae9bf1027cf405f7309685327abd67f1bf One point that would speak for non-expandable tabs, though, is that drag and drop to the breadcrumb bar gets harder with expanded tabs. Dragging over the tab might cause an unwanted switch to that tab. This was less of a problem when tabs were at the bottom (which was the case when the expanding-tabs commit was done).
(In reply to comment #3) > > The argument in favour of the current approach is, > > I guess, that a bigger tab is easier to click on > > Not quite. Here's the commit with an explanation: > http://git.gnome.org/browse/nautilus/commit/?id=fb39afae9bf1027cf405f7309685327abd67f1bf Thanks for the clarification. Looks like bug 125250 needs to be fixed before we can sort this.
(In reply to comment #3) > > The argument in favour of the current approach is, > > I guess, that a bigger tab is easier to click on > > Not quite. Here's the commit with an explanation: > http://git.gnome.org/browse/nautilus/commit/?id=fb39afae9bf1027cf405f7309685327abd67f1bf > > One point that would speak for non-expandable tabs, though, is that drag and > drop to the breadcrumb bar gets harder with expanded tabs. Dragging over the > tab might cause an unwanted switch to that tab. This was less of a problem when > tabs were at the bottom (which was the case when the expanding-tabs commit was > done). May be it is worth to add an option for easily switch between tab's modes. It is not necessarily to put this option to preferences. This place can be only in gconf settings.
(In reply to Allan Day from comment #2) > * It's inconsistent: Gedit, Epiphany and Empathy all have fixed width tabs > (GNOME-Terminal doesn't though - bad GNOME Terminal). Dialog tabs are also > have limited widths. In the meantime things have changed a bit. gedit, Terminal and Files all have expandable tabs. Text is now centered.
As mentioned in comment 6, expandable tabs are the de facto standard now for dynamic tabs. The HIG seems to assume so as well, when arguing 'a contrario' for fixed tabs. https://developer.gnome.org/hig/stable/tabs.html.en Allan, is this still something we want?
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.