GTK: Strategy for Hiding the Tab Bar

[ofseed]

libadwaita/gtk provides a tab bar that automatically hides by default, but I think it would be better to offer a way for users to always hide/show it, which has two benefits:

1. Prevent the size of the terminal layer from being changed, which would cause the layout of internal applications to change (for always show);
2. The length of the tab bar is fixed, which means that the number of tabs that can be displayed at once is limited, while libadwaita provides a tab overview that can better display a large number of tabs (for those that are always hidden).

The topics to be discussed include:

1. Is this feature necessary?
2. When the tab bar is always displayed, is it allowed to merge the title bar with the tab bar? Similar to black box;
3. When hiding the tab bar, should we use AdwTabButton (which can display the number of open tabs) instead of the current button (which has a static icon)?
4. Can the same behavior be achieved on other platforms?

Additionally, there is an extra benefit to using AdwTabButton as it is a native component of libadwaita, providing tooltips with i18n. I personally recommend using it at all times to achieve consistent and maintenance-free i18n translations; otherwise, the behavior of both types of buttons should be unified.

[mitchellh]

I renamed the issue to be GTK specific, because I think the goal especially with GUI chrome is to really remain true to the native elements and not force anything cross-platform that doesn't make sense. A good example is our AdwToast usage for example, which doesn't really have a specific analog on macOS.

In that vein, I'll note my thinking:

1. Is this feature necessary?

You're the first person to ask for it, so I'd say that's some signal that it's not that important. But, that doesn't mean we can't look into it or that future folks won't enjoy the changes once made.

2. When the tab bar is always displayed, is it allowed to merge the title bar with the tab bar? Similar to black box;

macOS already has a feature that does this called macos-titlebar-style = tabs. I love the look personally and if there is a way to bring it over to GTK without too much commotion I'd be interested in seeing it.

The remaining questions I defer.

I think it'd be good to cc in the folks that care deeply about GTK: @Pangoraw @jcollie @tristan957

[jcollie]

About merging the tab bar with the header bar: only if it's an upstream feature in GTK/libadwaita. I've seen the pain that the macOS apprt has gone through dealing with customizing the "native" experience and I don't really want to bring that to GTK.

I've seen a couple of people on Discord and elsewhere request always/never enabling the tab bar so I think that there's support for this. And the code isn't very intrusive so it won't be difficult to maintain.

[tristan957]

It's a feature @jcollie of GTK. GtkWindowHandle and GtkWindowControls allow you to basically create your own titlebar. Though I wonder if we could abuse the header bar's child widget for this purpose. Worth a shot.

[jcollie]

I think that it'd be easier to support if we make the switch to UI builder files rather than creating everything procedurally. That'll take a bit of work. Be nice to drop support for non-libadwaita builds as well.

[ofseed]

Regarding dropping non-libadwaita builds, I remember seeing an issue about it, but sorry, I can't find it now. Although I've been a long-time non-GNOME user, I personally support this because it can reduce maintenance burdens, and there doesn’t seem to be a way (or a need) to implement tab overview in GTK. Based on my experience with KDE two months ago, the performance of GTK builds may not be as ideal.

In any case, one thing to consider is that this decision would be very difficult to change once this repository is made public, which could lead to significant reactions from the community.

[tristan957]

I think that it'd be easier to support if we make the switch to UI builder files rather than creating everything procedurally. That'll take a bit of work. Be nice to drop support for non-libadwaita builds as well.

Moving to blueprint files would be awesome. I'm also not enthusiastic about continuing to support vanilla GTK in tree. But it's something that Mitchell wants to continue to support.

[tristan957]

I hacked something up using adw_header_bar_set_title_widget():

I think the proper solution is to do what Black Box does, but it should give you an idea. Dragging tabs does work as you would expect. Grabbing the window to move it becomes tougher.

I'm for supporting this configuration. I think it could be a pretty sweet thing. I can probably work on this unless someone feels eager.

[jcollie]

Is anyone against moving the new tab button?

No, especially if we add the next/prev tab buttons like it shows on the rearmost window.

[tristan957]

Mitchell had reverted a commit of mine which moved the button when I added tab overview support, so I think he is the person we have to convince.

[mitchellh]

I moved it to match Gnome Console so it felt familiar. I think if we do titlebar tabs and it looks different I'm more open to it.

[tristan957]

I think it is weird that GNOME Console is different from all these other first party GNOME applications (except for Ptyxis, which isn't a first-party app but gets design input from GNOME designers).

[pluiedev]

I like this. It's not quite as seamless as how it looks on say, iTerm2, but it's pretty damn clean.

[jcollie]

Also, having the tab bar visible when only one tab exists in that window enables you to use the tab bar header to drag that tab to a different window (after which the old window would close since it has no tabs anymore). AFAIK that would be the only way to move the last tab in a window to a different window.

[ofseed]

I think the proper solution is to do what Black Box does, but it should give you an idea. Dragging tabs does work as you would expect. Grabbing the window to move it becomes tougher.

I still prefer AdwTabButton, for the same reasons mentioned above, that is:

1. Displays the number of tabs, more useful when hiding tabs;
2. Has built-in i18n support.

[mitchellh]

Do you (or anyone else) have screenshots or a video showing how this normally looks in a native application? I see some screenshots of the widget alone and it looks good but curious how it fits into the bigger UX picture.

[tristan957]

There is some guidance at https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.TabButton.html which we should implement for the tab overview

[ofseed]

It is like this:

[ofseed]

My idea is that after we hide the tab bar, we can use this button to know how many tabs we have opened. And when we want to move to a specific tab, we can use the tab overview to accomplish this operation.

[tristan957]

Implemented in #2729.

[00-kat]

I'm not 100% sure what this discussion is about, but #5590 looks like it may also solve this if it wasn't solved in #2729.