GNOME Bugzilla – Bug 672433
use app menu and drop menu bar
Last modified: 2021-06-10 20:18:58 UTC
It would be wonderful if we could make Terminal use the GNOME 3 app menu and drop use of the per-window menu bar. Some recommendations: note when I say drop I only mean fro he Help - About -> app menu - Help -> app menu Tabs -> drop entire menu Terminal - Set title -> drop - Set character encoding -> context menu? - Reset -> drop - Reset & Clear -> app menu as "Reset" - sizes -> drop Search - Find -> app menu View - Show menubar -> drop - Fullscreen -> app menu - zoom -> drop Edit - Copy/Paste -> content menu - Profiles/Shortcuts/Preferences -> app menu Preferences File - New terminal -> app menu New window - New tab -> drop (use visual new tab) - New profile -> drop (add to profiles part of preferences) - Close tab -> drop (use visual) - Close window -> drop (use X)
Let's not confuse things; adding support for the appmenu and dropping the per-window menubar are different things. I'd prefer to separate these. I'm perfectly ok with adding an appmenu. This requires that g-t uses gtkapplication, which is already done on the gsettings branch. So if anyone wants to work on it, that's the branch to use. (Note that it's NOT ready to be merged until gsettingslist exists in glib.) Now about dropping the menubar, I'm not so sure. And we certainly will *not* be dropping *features* like you propose (e.g. reset without clear, list of tabs, the predefined sizes, zoom). Can you elaborate what you mean by 'visual' in comment 0 wrt. new tab/close tab ?
I don't think separating the two things makes any sense. The big win is removing the window menubar. So consider this bug about that if you like.
(In reply to comment #1) > Let's not confuse things; adding support for the appmenu and dropping the > per-window menubar are different things. I'd prefer to separate these. > > I'm perfectly ok with adding an appmenu. This requires that g-t uses > gtkapplication, which is already done on the gsettings branch. So if anyone > wants to work on it, that's the branch to use. (Note that it's NOT ready to be > merged until gsettingslist exists in glib.) > > Now about dropping the menubar, I'm not so sure. And we certainly will *not* be > dropping *features* like you propose (e.g. reset without clear, list of tabs, > the predefined sizes, zoom). I don't think all these features should be dropped altogether (at least Zoom is useful, I never used the other options myself to be honest), but they could just be moved out of the window chrome and into the context menu/preferences where it makes sense. I also agree having both a menu bar and an application menu visible is not really useful and potentially confusing.
Losing the menu bar would be fantastic. There's a lot of complexity there (I often can't remember which menu contains the particular item I'm looking for; I'm sure there are others who are the same). It also looks visually awkward and, you know, what has 'File' got to do with a terminal anyway? ;)
(In reply to comment #3) > I also agree having both a menu bar and an application menu visible is not > really useful and potentially confusing. I don't really agree with that. It's better to have some consistency with other applications than have a menu that only contains quit, and I think an app menu can coexist with a menubar. It'd be great to see a terminal app menu in 3.6. That said, it would be great to replace the menubar and I'd love to take that discussion further, but maybe a bug report isn't the best place to do that. Christian - would you like to talk it over some time?
g-t on git master already uses GtkApplication and has a rudimentary app menu. However, master won't be released as 3.6 since it's not in a releasable state and won't get there in just a few months. (Most importantly, it's waiting for GSettingsList.) For 3.6, we'll branch gnome-3-6 off of gnome-3-4. I'd like to avoid doing too much changes there, so a complete port to GtkApplication is out. However, just using a GtkApplication in non-unique mode should get use an app menu. Also, I don't think we should port from GtkUIManager to GMenu at this point. If an app menu action needs to perform an action in a window, I've written an adaptor for evince (bug 674937) [http://git.gnome.org/browse/evince/commit/?h=wip/app&id=c72ba10280dcec7884d326fb271b67c661723e69] that could be used here too.
+1 to drop menu bar
+1 drop menu bar. As William mentioned, many things can go into the app menu. Others can go into the context menu, and the things which Christian doesn't want to remove ("reset without clear, list of tabs, the predefined sizes, zoom") could go into a gear menu. The trouble is that there's no chrome when there is only one tab... What if options related to tabs went into a gear menu that appeared with the tab bar. Reset w/o clear, sizes, zoom can all go in context (right-click) menu. Also, it's not like those options will go away, afaik they're still available in the keyboard shortcuts menu. In all my uses & sightings of gnome-terminal, I've never once seen these less common features used...
What about a toolbar for the common per-window stuff? That also gives some chrome for a gear menu.
Created attachment 248540 [details] [review] To organize the app menu as the design The 'Help' app menu should be before the 'About' app menu. See mockups: https://raw.github.com/gnome-design-team/gnome-mockups/master/terminal/terminal-menus.png btw, I started to implement the design.
(In reply to comment #10) > btw, I started to implement the design. Has that design actually been reviewed and approved by the design team? Also, it hasn't even been discussed with the gnome-terminal maintainers.
(In reply to comment #10) > Created an attachment (id=248540) [details] [review] > To organize the app menu as the design > > The 'Help' app menu should be before the 'About' app menu. I looked in gnome-documents, and it has About, Help, Quit in that order. I presumed they have the right order...
(In reply to comment #11) > (In reply to comment #10) > > btw, I started to implement the design. > > Has that design actually been reviewed and approved by the design team? Also, > it hasn't even been discussed with the gnome-terminal maintainers. One third of the team (me) was involved in that mockup. Another third (Jakub) hasn't commented on it. Another third (Jon) will probably think that it is an improvement but includes lots of things that need to be improved. Either way, I should emphasise that the design is intended as a first iteration for moving to a header bar and app menu arrangement. I'm assuming that some adjustments will be necessary. Thanks for working on this, Yosef!
Created attachment 248699 [details] screnshot without/with tabs I've been experimenting with new design ideas too. Ie in the attached screenshot how I think g-t could look without tabs. In any case, let's take this redesign incrementally. Ie first add a toolbar or headerbar instead of the menu, with (one or more) menu/gear buttons that regroup *all* the existing menu items, and then go at moving around / regrouping the items themselves. Please publish a git repo with your in-progress implementation, so that I can provide feedback early before it becomes too hard to change / rebase it again.
Must-fix for 3.12 (due to bug 708346).
Please make it so that there is some way to hide the header bar (perhaps when full-screen is pressed?). Maybe there should be a full-screen button on the headerbar.
(In reply to comment #0) > Terminal > - Set title -> drop This menuitem does not work and we have agreed to drop it. There is a patch in bug 724110
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7166.