It is precisely because gnome-terminal is a mature and essential application that it doesn't "yet" use a header bar. A header bar would add nothing to it, but some regressions in usability:

- A headerbar is taller than server-side decorations, so using one would increase the vertical space taken up by not-content (the content in gnome-terminal's case is the terminal, of course).

- Headerbars don't work the same as server-side decorations (bug 705825, bug 729784, bug 729788, probably more).

Now, there is some (small) value in consistency with the other 'gnome' applications, too, so I would be willing to accept patches that make gnome-terminal *optionally* use a header bar. Making that option *default* to true would require fixing all of the mentioned problems above, however. (Distributions will likely disregard those problems and just override the pref, I fear.)

A header bar would likely need to incorporate the menubar and possibly also the tabs bar, so this isn't easy work. I'd also suggest that the gmenu port (bug 745329) should be finished beforehand.

Hi,

Christian is much better in picture of the current status, and why it hasn't been / when it will be implemented.

I'd just like to add two things:

1. I might not be the typical user, not aware of Gnome's current status. The apps I run in roughly decreasing frequency are gnome-terminal, firefox, gedit, gimp -- and that's all. None of them seem to have a header bar / client side decoration. This, of course, might not be the typical representation of a Gnome user's desktop.

2.

> As Gnome-Terminal is an app used by many(most) of us daily, it is concerning
> to see its lack of progression

Gnome-Terminal has progressed a lot during the last few years. Most of its progresses happened under the hoods though, not clearly visible on the UI at the first glimpse. It's really valid and welcome to raise the question about the lack of header bar / CSS - actually I myself am in doubt why it hasn't happened. But please don't say it lacked progression, as it's simply not true :)

typo: CSD

Fair enough, it was not my place to comment on the progression of Gnome-Terminal, but rather the outward visibility of said progression. Also, I would like to point out that Gedit does have a headerbar ;-)

Also, the height difference between headerbars and server side decoration from my eye is not very considerable. It seems that a headerbar using current Adwaita themes is only ~15-20pixels taller, but with all the functionality that you gain with CSD/headerbars that doesn't seem like such a bad tradeoff.

Further, looking at Gedit's implementation of the headerbar, they actually save vertical real estate by fully moving their traditional menu up onto the header through the clever use of popovers. In fact, the single Gedit cogwheel popover has the equivalent options of Gnome-Terminals File, Edit, View, Search, and Help tabs, with the "Terminal" tab easily being analogous to Gedit's "open" popover.

Further with multiple tabs open in Gedit vs Terminal, Gedit actually saves screen real estate by only having the headerbar + tab bar, whereas terminal has the Top Bar + menu bar + tab bar which comes out to more vertical pixels. (I will attach a screenshot illustrating this point).

Superficially (as I do not know the codebase, to which I defer to your expertise), it seems like Gnome-Terminal could adopt almost the exact same design decisions as Gedit, and actually capitalize on vertical screen real estate, enhance the visual attractiveness of the terminal, add further cohesiveness between core Gnome apps, and even future-proof the app a bit as GTK3+ progresses onwards.

Created attachment 313704 [details]
Screenshot comparing Terminal to Gedit headerbars

This screenshot shows the screen real estate loss/gains for each implementation. I would argue the Gedit implementation is superior aesthetically and usability wise, but I am just one person with an opinion.

(In reply to Britt Yazel from comment #4)

> Also,
> I would like to point out that Gedit does have a headerbar ;-)

Yup, I was indeed wrong here.

> Further, looking at Gedit's implementation of the headerbar, they actually
> save vertical real estate by fully moving their traditioal menu up onto the
> header through the clever use of popovers.

The traditional menu can be turned of in g-t. (In fact I use Ubuntu Unity where it's moved to the very top of the screen automatically, that's why it's a non-issue for me. I know it's not the stock Gnome experience, and that's why I'd let Christian say the final word.)

> In fact, the single Gedit
> cogwheel popover has the equivalent options of Gnome-Terminals File, Edit,
> View, Search, and Help tabs, with the "Terminal" tab easily being analogous
> to Gedit's "open" popover.

Speaking of popovers, if we could move the new search bar to the header of the window, that'd save us from quite some trouble in bug 755653, so I think it's really an idea worth considering!

CSD would definitely be weird to me for a while, but I guess I could get used to it, and I do see the rationale behind switching. I just unfortunately don't have the experience (and I'm not in the position) to make the decision, nor to write the code. But I'd really recommend to Christian to give it a good thought :)

Created attachment 313715 [details]
Screenshot showing gnome-terminal with as little chrome as possible

To add to Christian's position, I find it justified too by the fact that in a terminal, many users interact only via the *keyboard*, and have no interest whatsoever in mouse-focused buttons/menus.

CSDs shine for potentially-mouse-heavy apps because they let application creators expose actions in a more elegant and compact way than the good'ol' menu+toolbar combo. But there's already no need for a toolbar in gnome-terminal, and many users plain disable the menu bar! So,
  a. What would be the actions deserving room in the header bar?
  b. Supposing question a. above yields a few items, is the chrome cost worth the accessibility benefit?

Here is a screenshot of my setup, to illustrate my point. With:
 - only one tab (causing the tab bar to be hidden)
 - a disabled menubar
 - and a GTK theme minimizing the size of regular title bars

There's basically no chrome here! Just a beautiful terminal :)

As already mentioned, accessibility caveats apply: it's heterogeneous with the rest of the GNOME apps, and if a novice user accidentally hides the menu bar, s/he might get lost.

Honestly I think the Gedit people have a perfect implementation for how G-T should do it. Like I said above, if you swap out the "Open" popover for a "terminal" popover, containing all of the character encoding/reset/clear options, followed by the Tab button (as right now you must have 2+ tabs open for the new tab button to appear). Next, if you could embed tabs into the headerbar it would be ideal, as the "window title" for a terminal window is kind of useless imo as it is already the tab label. On the right hand side you could have a search button with new popover search dropdown, a cog wheel (with all of the settings being taken up by File, Edit, View, and Help), and the close button.


|---------------------------------------------------------------------------|
|-|Term|-|NTab|---|   Tab1   |-|   Tab2   |-|   Tab3   |---|Search|-|Cog|-|X|
|---------------------------------------------------------------------------|


And, the beauty of implementing all of the menu options with popovers is their dynamic nature. The single cogwheel in Gedit is enough to store not only links options menus, but actual configuration options on multiple of dynamic pages within the singly popover, thus needing less window based config options.

Or we could swap the New tab and search from my above example if that seems more intuitive. Again, I am not a designer, I'm just some guy.

I think i have to agree with Britt Yazel idea of implementing the headerbar for terminal app. The reason is consistency, For a novice user i think we should make it look like other core apps so that s/he doesn't feel the difference. From the usability point of view, headerbar for terminal is a must in my opinion.

There's a design page for tabs in the headerbar 
https://wiki.gnome.org/Design/Playground/Headertabs

I know Alan Day is most involved with UI/UX design of core Gnome elements. Is it possible for this bug to be placed on his radar? He may have some ideas for this that could be beneficial

One could come up with something like this for the terminal:
https://bugzilla.gnome.org/show_bug.cgi?id=741904

A new application for Gnome3, titled Terminix, I believe is a nice example of how a headerbar could work in a terminal application. Further, Terminix adopts some nice grid features from Builder which is a nifty idea.

Created attachment 325390 [details]
Terminix headerbar + right click context menu

For anyone who is still interested in this feature request, this is Terminix's implementation of a terminal headerbar with a right click context menu supplying lots of nice information. Terminix also goes a step further and allows you to disable the right click context menu and replace it with a bar just below the headerbar to store those options. I, however, like the vertical realestate captured by making use of a well implemented context popover.

I would love to hear input from the current Gnome-terminal maintainers as to whether or not they still disagree with these design choices,

(In reply to Egmont Koblinger from comment #6)
> (In reply to Britt Yazel from comment #4)
> > Further, looking at Gedit's implementation of the headerbar, they actually
> > save vertical real estate by fully moving their traditioal menu up onto the
> > header through the clever use of popovers.
> 
> The traditional menu can be turned of in g-t. (In fact I use Ubuntu Unity
> where it's moved to the very top of the screen automatically, that's why
> it's a non-issue for me. I know it's not the stock Gnome experience, and
> that's why I'd let Christian say the final word.)

Not all of the menu items are available in the popup menu when the menu bar is turned off, so occasionally you have to turn it back on. I do like what Unity does with menus (especially the option to put them in the window titlebar), but not everybody uses that, and I prefer GNOME overall.

I think replacing the menu bar with a button in the CSD is a good idea. Menu bars look old-fashioned now. I'd also suggest having something different popup when it's clicked rather than mirror the current menu bar in a top-level menu. For example, calling the first two headings "File" and "Edit" is taking convention too far, they don't really fit with what those submenus do in a terminal.

(In reply to Britt Yazel from comment #8)
> Next, if you could embed tabs into the
> headerbar it would be ideal, as the "window title" for a terminal window is
> kind of useless imo as it is already the tab label. On the right hand side
> you could have a search button with new popover search dropdown, a cog wheel
> (with all of the settings being taken up by File, Edit, View, and Help), and
> the close button.

I'm not so keen on this idea, because it compromises on the horizontal space available to tabs. There might not be enough room to show meaningful information in them eg long cwd paths. But this is part of a bigger problem anyway: the paths might be too long even for the widest tab, or a user might have several shells open with the same cwd. ROXTerm had an option to override the tab titles in response to user demand.

(In reply to Egmont Koblinger from comment #2)
> 1. I might not be the typical user, not aware of Gnome's current status. The
> apps I run in roughly decreasing frequency are gnome-terminal, firefox,
> gedit, gimp -- and that's all. None of them seem to have a header bar /
> client side decoration. This, of course, might not be the typical
> representation of a Gnome user's desktop.

Well, gimp isn't very representative of the cutting edge of UI design ;). Firefox [1], along with several other non-GNOME applications, also shows that the "File", "Edit" ... menu bar is disappearing and has a menu button instead, more in common with CSD than the traditional layout. These menu buttons also usually pop up something more sophisticated than a vertical list (see also comment #16).

[1] I think in Ubuntu it does still have a menu bar, but it doesn't in Debian.

A few things:

(a) When I recently brought this up with Allan, he wasn't convinced about using a headerbar.

(b) I would love to figure out a way to get rid of the menubar. I know there is a setting to disable it, and that is how I use it. However, there are things in the menubar that are not available otherwise, so disabling it can lead to loss of functionality. Would be nice to offer less chrome to everybody without any loss of functionality, and one less setting.

(c) A server-side decorated, *menubar-less* gnome-terminal window has less chrome than a client-side decorated, headerbar-using gnome-terminal.

(In reply to Debarshi Ray from comment #19)
> A few things:
> 
> (a) When I recently brought this up with Allan, he wasn't convinced about
> using a headerbar.

But look how great it is in Terminix! It really makes Terminix look like a modern and advanced terminal emulator
> 
> (c) A server-side decorated, *menubar-less* gnome-terminal window has less
> chrome than a client-side decorated, headerbar-using gnome-terminal.

I agree that if maximizing space is the only concern, getting rid of the menu bar wins. However, there is the concern that this is a core Gnome app, and Gnome user interface guidelines say that we should be using CSD+headerbar. If this was a separate project, I would not make this case, but as it is a core app I feel it should adopt the broader styling decisions of the project.

Lastly, as Terminix is a live implementation of exactly the argument I am making. I request all of us try Terminix and test it for our own workflow, and base decisions on that, rather than hypotheticals

I've tried Terminix/Tilix, but because of (c) I've switched back to GNOME Terminal.

Note that I'm also using https://extensions.gnome.org/extension/1267/no-title-bar/ which makes the difference even bigger when maximized (because it doesn't work with a header bar).

In bug 782765 it was requested that we show two lines of information in the header bar (as e.g. gedit or yelp do). The mock screenshot over there, however, contains two lines of text settable from the terminal emulator, which requires extending the OSC 0 escape sequence or adding a new one, I wouldn't want to do that.

On the other hand, it's often requested to bring back the possibility of manually setting a title (and I think Fedora patches it back). It seems to me that this feature was dropped mainly because the interaction between the manual vs. escape sequence title wasn't clear, and/or whatever was implemented couldn't clearly be communicated on the UI. (I'm not sure though.)

So I'm wondering, whenever we end up implementing header bar:

Should we maybe have a two-line title, one being what the terminal emulator asks us (via OSC 0), and the other (optional) one being the revived feature of manually setting one? Does this make sense? (Not sure, I'm just leaving this idea here for future consideration.)

(In reply to Egmont Koblinger from comment #22)
 
> On the other hand, it's often requested to bring back the possibility of
> manually setting a title (and I think Fedora patches it back). It seems to
> me that this feature was dropped mainly because the interaction between the
> manual vs. escape sequence title wasn't clear, and/or whatever was
> implemented couldn't clearly be communicated on the UI. (I'm not sure
> though.)

I implemented something like that for roxterm's tab names, allowing them to include a "%s" to substitute the terminal's title. I may not have been diligent in checking for abuses of the format string though :-/.

*** Bug 782765 has been marked as a duplicate of this bug. ***

Bug 782765 has some ideas and a mockup.

I think the question here is less how to use a header bar, and more how to improve gnome-terminal's header more generally. Here, I think the main goals should be to:

 - Reduce the vertical footprint of the chrome, to show more text and give a more streamlined feel
 - Reduce the UI "surface area", particularly with regards to the menu bar, to make the UI simpler to use
 - Expose search, since that's useful and currently hidden
 - Generally, look nicer and appear more modern
 - Where possible, be consistent with other GNOME apps

Last week I sketched an idea for how to do this: https://gitlab.gnome.org/Community/Design/app-mockups/blob/master/terminal/terminal.png

The height of the chrome in this mockup is 40px. That's 66px less than the current Terminal default.

Looks good. Did you have to separate the notebook tab area and the main content or does it work correctly if you pack the whole lot into the header bar with a zero-sized window body?

(In reply to Tony Houghton from comment #27)
> Looks good. Did you have to separate the notebook tab area and the main
> content or does it work correctly if you pack the whole lot into the header
> bar with a zero-sized window body?

It's a mockup.

(In reply to Allan Day from comment #28)
> (In reply to Tony Houghton from comment #27)
> > Looks good. Did you have to separate the notebook tab area and the main
> > content or does it work correctly if you pack the whole lot into the header
> > bar with a zero-sized window body?
> 
> It's a mockup.

Do you mean you mocked it up from images? I thought you might have done it with glade or python or something like that.

(In reply to Tony Houghton from comment #29)
...
> Do you mean you mocked it up from images? I thought you might have done it
> with glade or python or something like that.

Sorry - yes, it's an image.

The first step to implement that would be for someone to write a tab strip widget for use as a GtkStack switcher.

(In reply to Christian Persch from comment #31)
> The first step to implement that would be for someone to write a tab strip
> widget for use as a GtkStack switcher.

That could be helpful, because GtkNotebook does cause me some issues with label size allocation in roxterm due to its always-show-tab-bar option. Some other apps could benefit from such a widget too, eg gedit.

But if nobody wants to write a new widget couldn't you use two notebooks, one with an invisible tab bar and one with zero-sized child widgets? Page switch signals could be forwarded from the latter to the former.

> two notebooks, one with an invisible tab bar

That's pretty much what a GtkStack is :)

> and one with zero-sized child widgets? Page switch signals could be forwarded

I _guess_ it's doable, but a bit hackish. If other apps are likely to use this as well, it's probably better if there's a stock solution for it.

(In reply to Egmont Koblinger from comment #33)
> > two notebooks, one with an invisible tab bar
> 
> That's pretty much what a GtkStack is :)

True, but that's not so nice aesthetically. We want a sort of best of both: tabs that look attached to a page widget below them but where the tabs can be packed into a header bar and the page packed into a window body. That's what the main browsers are doing nowadays (except that Firefox for Linux doesn't use CSD yet, and it now looks klunky). A new subclass of GtkStackSwitcher would be a good way to implement it. The one small issue that GTK devs might not like is that it puts more responsibility onto clients not to misuse it and come up with something odd-looking where the tabs don't appear related to what's immediately below them.

> > and one with zero-sized child widgets? Page switch signals could be forwarded
> 
> I _guess_ it's doable, but a bit hackish. If other apps are likely to use
> this as well, it's probably better if there's a stock solution for it.

Well that would just be a pattern for gnome-terminal and similar apps to adopt, not some sort of library component.

Header Bar is now being freshly discussed and implemented at https://gitlab.gnome.org/GNOME/gnome-terminal/issues/44.

Shall we close this as OBSOLETE, then? It's confusing to track this in two places.

Yeah, let's not jump back and forth. Let's continue only at https://gitlab.gnome.org/GNOME/gnome-terminal/issues/44.