Some newer toy apps are using the Gears menu, also Gedit and Firefox.
But there seems to be many larger programs like GMail (Evolution), Gimp, Inkscape and even the Gnome terminal which still uses textual menubar.
So I wonder what to use for medium size application. For toy apps with only few menu entries gears menus seems to be fine, and they look more “modern”.
But I wonder if using tools like Inkscape with gears menu would become less user friendly.
I have recently tested both, textual menu and gears menu together with GAcctions, using the Nim bindings. Both is fine, but it is hard to decide which to use. I guess I will use gears menus, because of the more modern look, but usage for users may become difficult if the menu gets many entries.
Personally, I’d make the decision based on how many items there are, how many of those are used every session and whether you expect different items to be used each session.
GIMP for example, has a lot of items, and other than open/save, it’s likely you’ll use different items each session. Gedit on the other hand, you will probably use open/save/new almost every session and far less frequently use any other item.
One question is, “do you want to devote window space to a menu?” If you don’t want it, then you hide that menu behind an icon in a header bar. If your program has a lot of toolbar buttons, then you probably don’t want to use up more space for an always visible menu.
Thanks for your answers, which mostly seems to support my own feelings.
So textual menu bar is not really deprecated – for tools like gimp or incscape it may be still justified.
The fact that gnome terminal still uses textual menu may have legacy reasons, gears menu may be a better option.
My conclusion is, that I will generally start with gears menu, and maybe later switch to textual menu if I notice that I have many menu items most of them used often.
By the way, recent GNOME Terminal (3.32, IIRC) supports the pop-up menu and hides the menu bar (which contains some less frequently used features) by default. This is useful if only a small subsection of functionality is used most of the time. Firefox also chose this approach, with an extra feature that the menu bar is shown when user presses alt key.
Previously, there were also app menus, and you could set both app menu and a menu bar and GTK would choose which one to show based on the user’s desktop environment. Unfortunately, the app menu is now deprecated and it would go to the app icon in the header bar, rather than the gear menu (example). It might still be a good idea to provide both gear menu and menu bar if there are not many actions in the gear menu but you also want to target non-GNOME platforms, but you will probably need some extra code to only show one of them.
Additionally, in larger programs, it is useful to provide a command palette that will allow user to quickly search for an action using keyboard. The web-era text editors like Sublime Text open it with ctrl-shift-p and GIMP with / key. There is also a GTK module Plotinus, that supports that pattern independently of application but since modules like these will not be supported for GTK 4, you would need to implement it application-side.
The plan is to move more and more towards declarative menus, which would allow the toolkit to implement the same functionality as Plotinus. In general, we want app developers to describe their menu structures, popovers, and contextual menus using XML and GMenu/GAction. Menu bars and nested menus are still going to be supported, so it depends on the amount of actions available to the user whether or not a complex menu hierarchy or a simpler primary/secondary menu buttons are more appropriate.
