gnome-terminal issueshttps://gitlab.gnome.org/GNOME/gnome-terminal/-/issues2019-10-22T18:46:48Zhttps://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/176Provide select-by-word functionality2019-10-22T18:46:48ZGhost UserProvide select-by-word functionalityI use Gnome and gnome-terminals everyday at work, and I have recently migrated from Red Hat 6.x environment running Gnome2 to Red Hat 7.x running Gnome3. I am really missing the 'Select-by-word characters' feature that was under the Edi...I use Gnome and gnome-terminals everyday at work, and I have recently migrated from Red Hat 6.x environment running Gnome2 to Red Hat 7.x running Gnome3. I am really missing the 'Select-by-word characters' feature that was under the Edit Profile. This feature allowed me to **dynamically** alter the characters that a double-click action would select in my terminal. I used this feature extensively in order to dynamically change, for example, whether or not a '-' or a ':' would be selected. I am a developer that uses gnome-terminals all day long, for editing, cut/pasting between terminals etc. Could this select-by-word feature be added into the Gnome3 terminal 'Preferences' dialog to bring back this very useful capability ?
Thanks
-Todd Millerhttps://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/156Change "About" label to "About Terminal"2020-01-14T17:57:14ZJimmy SciontiChange "About" label to "About Terminal"Hi!
can you change the label "About" in the hamburger-menu to "About Terminal"? Most of gnome-apps follow this "standard" for such label.Hi!
can you change the label "About" in the hamburger-menu to "About Terminal"? Most of gnome-apps follow this "standard" for such label.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/153Feature: display timestamps as ISO 8601 strings in the contextual menu2019-08-20T03:32:12ZGhost UserFeature: display timestamps as ISO 8601 strings in the contextual menuThis patch allows to display the date corresponding to a timestamp in the contextual menu.
![Screenshot_from_2019-08-18_20-17-19](/uploads/56df267f51daa5159aef896810ef743a/Screenshot_from_2019-08-18_20-17-19.png)
[0001-Feature-display-...This patch allows to display the date corresponding to a timestamp in the contextual menu.
![Screenshot_from_2019-08-18_20-17-19](/uploads/56df267f51daa5159aef896810ef743a/Screenshot_from_2019-08-18_20-17-19.png)
[0001-Feature-display-timestamps-as-ISO-8601-strings-in-co.patch](/uploads/4c0b968042628c3c7289fe14c56537ec/0001-Feature-display-timestamps-as-ISO-8601-strings-in-co.patch)https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/143Any string that starts with "ftp" is recognized as an URL2020-09-02T05:23:01ZIgorAny string that starts with "ftp" is recognized as an URLInterestingly enough, vte test app doesn't do that.Interestingly enough, vte test app doesn't do that.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/142Feature Request: set tab header colours via control codes / tab icons2022-09-02T15:37:49ZGhost UserFeature Request: set tab header colours via control codes / tab iconsFeature request:
Allow the user to set the RGB background colour of the tab header from the command via control codes, like the implementation in iTerm2. This is useful for me because it allows me to quickly group and distinguish termin...Feature request:
Allow the user to set the RGB background colour of the tab header from the command via control codes, like the implementation in iTerm2. This is useful for me because it allows me to quickly group and distinguish terminal tabs for different servers I am ssh'd to. i.e. Production hosts use a red tab for that extra visual reminder not to mess things up!
Thank you very much for your consideration.
![terminaltabcolours](/uploads/12ef1ab651d08b68c05dec5f4b0d890d/terminaltabcolours.jpg)
See the attached file for the codes used by iTerm2
[iterm2tabcolors.txt](/uploads/9d3fc2ba6dcaeb8c3af04e876399d6ba/iterm2tabcolors.txt)https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/140Show zoom level, revise zoom values2021-09-23T15:12:23ZEgmont KoblingerShow zoom level, revise zoom valuesForwarding from [Red Hat 1702528](https://bugzilla.redhat.com/show_bug.cgi?id=1702528):
Original comment:
> Steps to Reproduce:
> 1\. Zoom in / out using +/- menu item from AppMenu.
>
> Actual results:
> The zoom percentage control...Forwarding from [Red Hat 1702528](https://bugzilla.redhat.com/show_bug.cgi?id=1702528):
Original comment:
> Steps to Reproduce:
> 1\. Zoom in / out using +/- menu item from AppMenu.
>
> Actual results:
> The zoom percentage control widget doesn't update reflecting the new zoom percent.
>
> Expected results:
> Zoom percentage control should update its value.
My response:
> That's a clickable button, and as such, its label displays the action to be executed: Change the zoom level to 100%.
Another commenter:
> Files has an identical widget that shows the \*current\* zoom level. (And resets the zoom level when you click on the label).
>
> Also, everyone will expect it to show the current zoom level, because that is what Firefox does :-).
@fmuellner What do you think, shall we go with Files's / Firefox's behavior?
---
As a prerequisite, we'd need to revise our zoom levels, and switch from jumping by a factors of 1.2 (up to ±7 steps from the default) to more human-friendly values. Our current percentages, rounded to the nearest integer are: 28, 33, 40, 48, 58, 69(*), 83, 100, 120, 144, 173, 207, 249, 299, 358.
(*) Actually 64, see GNOME/pango#372.
We could go with e.g. 25, 31.25, 40, 50, 62.5, 80, 100, 125, 160, 200, 250, 320, 400 percents. These are nice rational numbers and their reciprocals, most of them look friendly in decimal, and are pretty even on the logarithmical scale with factors of 1.25 and 1.28.
Files offers 50, 67, 100, 133.
Firefox offers 30, 50, 67, 80, 90, 100, 110, 120, 133, 150, 170, 200, 240, 300.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/131Add a shortcut to open the menu for new terminal profile selection2021-01-13T13:21:26ZGhost UserAdd a shortcut to open the menu for new terminal profile selectionIn the process of reviewing accessibility, and keyboard navigation, I think other shortcuts can be added.
Before Alt+F (for example) was giving the possibility to open the whole menu and navigate from there with arrows or other shortcuts...In the process of reviewing accessibility, and keyboard navigation, I think other shortcuts can be added.
Before Alt+F (for example) was giving the possibility to open the whole menu and navigate from there with arrows or other shortcuts there was access to all functionalities.
I would like to see a shortcut to open the new terminal dropdown where you can select the profile for the new terminal; like for the magnifying tool that can be opened with Ctrl+Shift+F; espectially if as by #91 F10 start to open directly the terminal menu.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/129[headerbar] Maximize or fullscreen back-n-forth shrinks the terminal2023-12-03T06:17:45ZEgmont Koblinger[headerbar] Maximize or fullscreen back-n-forth shrinks the terminalLet's continue from #44 and [751064](https://bugzilla.gnome.org/show_bug.cgi?id=751064) in a new bug to get rid of the previous noise.
Maximize or fullscreen gnome-terminal, then leave this mode. Only with headerbar, the size shrinks. B...Let's continue from #44 and [751064](https://bugzilla.gnome.org/show_bug.cgi?id=751064) in a new bug to get rid of the previous noise.
Maximize or fullscreen gnome-terminal, then leave this mode. Only with headerbar, the size shrinks. Both on X11 and Wayland.
It may actually be a gnome-terminal bug, let's see.
---
My setup:
- Physical screen: 1920x1080
- Font size: 9x18
- Initial terminal size: 80x24 cells
- Padding: 1px on each side
- (Initial VTE size derived from these: 722x434)
- Scrollbar width: 12px
- Headerbar height: 42px
- (Initial user-perceived real window size derived from these: 734x476)
- Shadow width: 74 px along both axes (around 37px on each side)
- (Initial overall size including shadows: 808x550)
---
Debug messages with `GNOME_TERMINAL_DEBUG=geometry` around a fullscreen+unfullscreen cycle:
```
80x24 cells of 9x18 px = 720x432 px
padding = 2x2 px
content area requests 734x434 px
chrome: 14x2 px
terminal widget allocation 734x434 px
window allocation 808x550 px
CSDs: 74x116 px
terminal widget requests 722x434 px
[window 0x558d25ce23b0] hints: increment unchanged, not setting
[window 0x558d25ce23b0] size is 80x24 cells of 9x18 px
[window 0x558d25ce23b0] 720x432 + 14x2 = 734x434
[screen 0x558d25cf15f0] size-alloc 722 : 434 at (36, 74)
[window 0x558d25ce23b0] size-alloc result 808 : 550 at (0, 0)
*** F11: enter fullscreen ***
[screen 0x558d25cf15f0] size-alloc 1982 : 1154 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1994 : 1154 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1994 : 1154 at (0, 0)
[screen 0x558d25cf15f0] size-alloc 1908 : 1080 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1920 : 1080 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1920 : 1080 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1920 : 1080 at (0, 0)
*** F11: leave fullscreen ***
[screen 0x558d25cf15f0] size-alloc 641 : 344 at (36, 74)
[window 0x558d25ce23b0] size-alloc result 727 : 460 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 727 : 460 at (0, 0)
[screen 0x558d25cf15f0] size-alloc 713 : 416 at (36, 74)
[window 0x558d25ce23b0] size-alloc result 799 : 532 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 799 : 532 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 799 : 532 at (0, 0)
```
---
Interpretation:
When entering fullscreen, the _window_ is first enlarged to (1920+74)x(1080+74) pixels, that is, my physical screen size plus the shadow. (The _screen_ is narrower by 12px due to the scrollbar.) Then the shadow is dropped.
When leaving fullscreen, the screen is shrunk to 641 pixels wide (71\*9+2) instead of 722 (80\*9+2). This value is suspiciously 722 (expected) - 74 (shadows) = 648 rounded downwards to respect the grid and padding. Correspondingly, the window becomes 727 pixels wide which is 641 + 12 (scrollbar) + 74 (shadows).
Ditto for the height: the screen becomes 434 (expected) - 74 (shadows) = 360 rounded downwards to match the grid to 344 = 19\*18+2 (19 lines + padding). The window height is correspondingly 344 + 42 (headerbar) + 74 (shadows) = 460.
Then the shadow's size gets re-added, and again, the sizes are rounded downwards to match the grid.
To double check that I'm on the right track, let's try to see what a `trap 'stty size' WINCH` says:
```
*** F11: enter fullscreen ***
64 220
59 211
*** F11: leave fullscreen ***
19 71
23 79
```
The intermediate 71x19 size is clearly visible, and there's a similar dance when going oversized.
---
So, during (un)maximize/fullscreen, the amount of CSD changes. The value printed in the debug messages `CSDs: 74x116 px` is no longer relevant. According to the lack of further similar debug messages, the value is not recomputed.
Maybe all we need to do is recompute the CSD dimensions at the right place, in an atomic step along with the resize? (Is it possible? Or do we derive the CSD values from other properties that we're just about to figure out during a resize, so there's a chicken-and-egg problem?)
---
[The `at (36, 74)` values (allocation->x/y) might indicate that the shadow is probably not evenly distributed. 36px on the left and the remaining 38px on the right. 74 - 42 (headerbar) = 32 pixels at the top and the remaining 42 pixels at the bottom. And then if I'm not mistaken it's just a coincidence that allocation->y's 74 is the same number as the overall shadow width per axis.]https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/111It's impossible to leave fullscreen mode via touchscreen2019-08-12T23:38:53ZRussianNeuroMancerIt's impossible to leave fullscreen mode via touchscreenHello!
After (maybe accindental) switch to fullscreen mode it's impossible to switch back to windowed mode via touchscreen. It could cause at least two following problems:
1. If device have hardware Meta button (like most of the x86 ta...Hello!
After (maybe accindental) switch to fullscreen mode it's impossible to switch back to windowed mode via touchscreen. It could cause at least two following problems:
1. If device have hardware Meta button (like most of the x86 tablets) user could press it and just close Gnome Terminal emulator. However, this is undesirable if there was few tabs open and another tab have running process that should be finished (for example file copying operation that running on remote server).
2. If there is no hardware Meta button (like HP Elite x2 1013 G3 Thinkpad X1 Tablet 3rd Gen) and typing exit is impossible for some reason (running "dmesg -w", stalled ssh session, etc.) there is no way to get access to other applications besides long power button press (because many tablet users configure power button action to suspend from short press).https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/102Add CI support2021-03-22T21:16:57ZIñigo Martínezinigomartinez@gmail.comAdd CI supportGitLab has support for Continuous Integration/Deployment pipelines. This can be achieved by using a `.gitlab-ci.yml` file.GitLab has support for Continuous Integration/Deployment pipelines. This can be achieved by using a `.gitlab-ci.yml` file.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/98Run shell when custom-command is empty / only contains whitespace2021-03-22T21:23:35ZTomasz KłoczkoRun shell when custom-command is empty / only contains whitespaceWhen I;m starting it from xfce terminal it shows:
<pre>[tkloczko@domek ~]$ gnome-terminal
# _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
# watch_fast: &quot;/org/gnome/desk...When I;m starting it from xfce terminal it shows:
<pre>[tkloczko@domek ~]$ gnome-terminal
# _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
# watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/settings-daemon/peripherals/mouse/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/sound/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/privacy/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/wm/preferences/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 0, active: 0)
# watch_fast: "/org/gnome/desktop/a11y/" (establishing: 0, active: 0)
# watch_established: "/org/gnome/desktop/interface/" (establishing: 1)
# watch_established: "/org/gnome/settings-daemon/peripherals/mouse/" (establishing: 1)
# watch_established: "/org/gnome/desktop/sound/" (establishing: 1)
# watch_established: "/org/gnome/desktop/privacy/" (establishing: 1)
# watch_established: "/org/gnome/desktop/wm/preferences/" (establishing: 1)
# watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 1)
# watch_established: "/org/gnome/desktop/a11y/" (establishing: 1)
# _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)
# Error: Text was empty (or contained only whitespace)
[tkloczko@domek ~]$
</pre>https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/95Client: Link against fewer libraries2023-11-10T18:23:06ZEgmont KoblingerClient: Link against fewer librariesCurrently g-t (client) and g-t-s (server) link against the same set of libraries; 80 libs in particular reported for me by `ldd`.
The client hardly does anything more than notifies the server to open a new window.
Could we reduce its l...Currently g-t (client) and g-t-s (server) link against the same set of libraries; 80 libs in particular reported for me by `ldd`.
The client hardly does anything more than notifies the server to open a new window.
Could we reduce its library use? It doesn't need to link against VTE (and in turn PCRE2, GnuTLS…), GTK and probably a couple more. Maybe we can even rid of GDK and thus Pango, HarfBuzz etc. in `terminal_client_get_fallback_startup_id ()`??
I guess this could have a nice impact on startup time.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/91Accessibility and keyboard usability of the new header bar2021-01-13T13:21:26ZPeter VágnerAccessibility and keyboard usability of the new header barSince gnome-terminal 3.32 we do have new header bar at the top.
I think it has a few accessibility issues and inconsistencies related to keyboard navigation.
When the gnome terminal is launched the terminal view has the focus.
Pressing t...Since gnome-terminal 3.32 we do have new header bar at the top.
I think it has a few accessibility issues and inconsistencies related to keyboard navigation.
When the gnome terminal is launched the terminal view has the focus.
Pressing the F10 key moves the focus to the header bar.
This is not very consistent with other gnome apps with a header bar. I think pressing F10 key should expand new menu the same way clicking on the right most header button does. Not only this would be more consistent with other gnome apps but it would also allow returning focus back to the terminal view by pressing the ESC key.
Ability to move the focus to the header bar should be added as a keyboard action into the settings with no default shortcut bound for those who are looking for such a functionality.
Additionally pressing F10 key when the menu bar is showing should inwoke the menu bar instead (also see #90).
Another issue with the header bar is that all the header bar buttons don't provide its name and description (perhaps derived from the tooltip) to the accessibility API so screen reader users can identify individual buttons.
Very frequent editing actions Select all and Copy are not yet available through the new menu that can be inwoked from the header bar.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/83alt+F8 and arrows: vertical window resizing shrinks only2021-04-08T23:29:15ZAdam Chasenalt+F8 and arrows: vertical window resizing shrinks onlyScenario: Using window resizing shortcut Alt-F8 and arrows to adjust the bottom or top of the window.
Shrinking the window operates as expected. Expanding the window takes no effect.
Note: Shift+arrow can expand vertically, but is a m...Scenario: Using window resizing shortcut Alt-F8 and arrows to adjust the bottom or top of the window.
Shrinking the window operates as expected. Expanding the window takes no effect.
Note: Shift+arrow can expand vertically, but is a much larger jump. (shift appears to snap to specific locations for all windows)
Environment: Fedora 29https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/76Support tmux control mode2020-12-26T13:13:35ZKevin LydaSupport tmux control mode[Tmux][tmux] supports a [control mode][control] which is supported in a small number of terminal emulators. I think the first implementation was done by [iTerm2][iterm2]. This was [previously raised][bug] in the Gnome Bugzilla but though...[Tmux][tmux] supports a [control mode][control] which is supported in a small number of terminal emulators. I think the first implementation was done by [iTerm2][iterm2]. This was [previously raised][bug] in the Gnome Bugzilla but thought I'd make a ticket here.
In addition to the links above, I see this discussion on the [control protocol][protocol] which would be useful for an implementation.
Is anyone else interested in working on this? Would the maintainers be interested in this as a feature?
[bug]: https://bugzilla.gnome.org/show_bug.cgi?id=745640
[control]: http://man.openbsd.org/OpenBSD-current/man1/tmux.1#CONTROL_MODE
[tmux]: https://github.com/tmux/tmux
[protocol]: https://github.com/tmux/tmux/issues/763
[iterm2]: https://github.com/gnachman/iTerm2https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/70Immutable user-defined tab title prefix feature2019-12-17T04:08:01ZGhost UserImmutable user-defined tab title prefix featureThis request resembles a feature dropped at or after version 3.14 of gnome-terminal: capability to define a user-defined part of title shown for a terminal tab. I.e., the title would look like "[prefix] [program-defined part]" where "pre...This request resembles a feature dropped at or after version 3.14 of gnome-terminal: capability to define a user-defined part of title shown for a terminal tab. I.e., the title would look like "[prefix] [program-defined part]" where "prefix" can only be defined through using a specific profile and/or manual user interaction/via command-line parameter.
Reasoning:
- proposed defining titles via ASCII escape codes is volatile (there's no way to define an immutable title part; a program running in the tab can change the title at any moment)
- if terminal is run in non-interactive mode, it might be not possible to define titles
The tab titles helped greatly to navigate across large sets of tabs/windows.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/67Touchscreen movements should scroll the terminal instead of selecting text2023-03-29T18:30:51ZPhilip Gotophilip.goto@gmail.comTouchscreen movements should scroll the terminal instead of selecting textWhen using the touchscreen trying to scroll the output of the terminal text gets selected. It's not possible to scroll using only a touchscreen without using the scrollbar, which is highly inconvenient. Touchscreen movements should scrol...When using the touchscreen trying to scroll the output of the terminal text gets selected. It's not possible to scroll using only a touchscreen without using the scrollbar, which is highly inconvenient. Touchscreen movements should scroll the terminal instead of selecting text. For selecting text, a long press followed by movement could be a trigger.
Tilix already does this (although scrolling is way too sensitive), and it would be nice if the standard terminal could also do this.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/58If --command is removed, how will we duplicate this use case (opening a windo...2023-12-12T23:28:10ZFeRD (Frank Dana)If --command is removed, how will we duplicate this use case (opening a window with multiple tabs running commands)?I noticed that if the `--command` option is used in recent `gnome-terminal` versions (I'm running Fedora 29 with the distro's current `gnome-terminal-3.30.2-1.fc29.x86_64.rpm` installed), it will output the following message:
```
# Optio...I noticed that if the `--command` option is used in recent `gnome-terminal` versions (I'm running Fedora 29 with the distro's current `gnome-terminal-3.30.2-1.fc29.x86_64.rpm` installed), it will output the following message:
```
# Option “--command” is deprecated and might be removed in a later version of gnome-terminal.
# Use “-- ” to terminate the options and put the command line to execute after it.
```
Our application (a GNOME Shell extension) launches `gnome-terminal` as a "log viewer" for the extension, when requested by the user, by firing off a `GLib.spawn_command_line_async()` containing a command that opens a two-tab `gnome-terminal` window showing two different views of the journal:
```javascript
GLib.spawn_command_line_async(
'gnome-terminal ' +
'--tab --command "journalctl cmd 1" ' +
'--tab --command "journalctl cmd 2"'
);
```
With the removal of `--command`, and the advice to place the command to run after a `--` options terminator, what will be the supported method of launching a two-tab terminal window in that manner? Will we have to split our single command apart into two, launching them individually?
Having to switch to this:
```javascript
GLib.spawn_command_line_async('gnome-terminal --tab -- journalctl cmd 1');
GLib.spawn_command_line_async('gnome-terminal --tab -- journalctl cmd 2');
```
doesn't seem that onerous on the face of it, but turning a formerly-atomic operation into a pair of discrete ones potentially raises all manner of concerns regarding timing and race conditions. What will happen if the second command fires off too quickly, and the window is not yet available to have a second tab added?
I don't care about `--command` per se, only about the useful and valued functionality it provides to us. If there's another, equally-effective way to achieve the same outcome we currently have with `--command`, then that's all I need. I'm just trying to work out the alternatives _now_, so that we don't get caught unawares if support for `--command` is dropped.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/51[Header bar] Design Search UI2019-04-03T15:56:08ZEgmont Koblinger[Header bar] Design Search UIForking off from #44, let's dedicate this issue for discussing the design of the Find functionality (location of the text entry, extra options etc.) when having a CSD header bar.Forking off from #44, let's dedicate this issue for discussing the design of the Find functionality (location of the text entry, extra options etc.) when having a CSD header bar.https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/50[Header bar] Design New Tab/Window UI2021-01-20T10:33:58ZEgmont Koblinger[Header bar] Design New Tab/Window UIForking off from #44, let's dedicate this issue for discussing the New Tab, New Window, New Terminal button(s) and menu entry(ies) of the header bar (including whether we'd like to keep or get rid of the unified-menu user setting).Forking off from #44, let's dedicate this issue for discussing the New Tab, New Window, New Terminal button(s) and menu entry(ies) of the header bar (including whether we'd like to keep or get rid of the unified-menu user setting).