GNOME Bugzilla – Bug 787342
Feature request: Show accelerator keys in MenuButton popovers and application menu
Last modified: 2018-05-02 19:03:43 UTC
Accelerator keys which are assigned to menu actions bound to the application menu or a MenuButton are not shown. Thus a user has usually no way to learn them while using the application. Note: This is not about menu bars, but about "hamburger menus" and similar (hence GtkPopover). Expected behaviour can be seen here: https://i.stack.imgur.com/6XFI0.png (older Nautilus) https://pasteboard.co/GJ2UNzJ.png (more recent GNOME Builder*) Actual results look more like this: http://1.bp.blogspot.com/-91GnxGBkPB0/UAbKGk4Q1iI/AAAAAAAAJVY/h_aphpPe8aI/s1600/nautilus-3.5.4-menu.png (no keys shown in the popover) Steps to Reproduce: Add an accelerator key to a menu entry using a .ui file, Gtk.Application.add_accelerator or Gtk.Application.set_accels_for_action. Make sure gtk-enable-accels is true. (I used the Vala language on Arch Linux with gtk+ 3.22.19.) It would be good to show the accelerator keys in the popovers because: * They would be directly associated to the menu action and could be learned on-the-fly: Open the menu, learn the accel for the action you use. * It is probably the *only* way to learn these keys in the application itself if it does not implement a keyboard shortcuts dialog like the one GNOME editor has. * I guess the GtkLables displaying the accelerator keys in GNOME Builder were probably hand-coded. It is the only menu in GNOME Builder showing them, by the way.
*** Bug 784167 has been marked as a duplicate of this bug. ***
(In reply to Sandwichmaker from comment #0) > * I guess the GtkLables displaying the accelerator keys in GNOME Builder > were probably hand-coded. I doubt it; they probably just use a GtkAccelLabel: https://developer.gnome.org/gtk3/stable/GtkAccelLabel.html
Regarding Builder, I did a bit more poking around. I'm new to gtk+ from a developer perspective, but this is what I found: * The button is named "perspective_menu_button" (according to GTK_DEBUG=interactive). * It seems to be declared in https://git.gnome.org/browse/gnome-builder/tree/libide/workbench/ide-workbench.ui as <object class="DzlMenuButton" id="perspective_menu_button"> * The DzlMenuButton has been introduced to libdazzle in version 3.25.4. From the release notes at https://github.com/chergert/libdazzle/commit/91469818c3e468fffc43f03d0fd67e64ed57abbc#diff-ff4e2dc4962dc25a1512353299992c8dR31 : > A new DzlMenuButton has been added that has a consistent style for a few > forms of MenuButton type scenarios. It can have icons, accelerators and > we expect in the future to keep the accelerator in sync with the active > shortcut theme. Some extended attributes with menus.ui are used. Maybe it would be possible to port code from libdazzle to gtk+ so users can see the accels in all gtk+ applications? But the gtk+ devs will know better than me what the best approach to implementing this in gtk+ would be.
This is largely a question about application design. In the past few years, we've generally been moving away from large menus with embedded shortcuts to more contextual actions with a centralized help overview.
We've also moved away from providing a very detailed api for menus with accelerators to a much more flexible system with popovers that are more or less generic containers, which does not easily lend itself to prescriptive rules like 'every item shall have a visible accelerator'
But then, as far as I know, a sizeable part of Christian's work on Dazzle has the aim of making it easier to wire up and synchronise accelerators, actions, icons, and the visual description thereof. I certainly hope so! I had to write my own helper in the meantime, to let me specify actions' names/descriptions, icons, accelerators, and callbacks in a single place - instead of having to remember to keep several pieces of code in sync with duplicates of accelerators, icons, etc. The manager keeps all that info, connects the callbacks, dishes out icons/labels/tooltips to Actionable buttons, etc. It's a bit of a behemoth, but it'll save me a lot of maintenance. I believe Sebastien has a somewhat similar goal with the AMTK part of Tepl, though more oriented towards traditional menus (of which I have none) than mine. So, while it's nice to have a completely open framework without being constrained to one model, it seems clear that a number of users might well appreciate a more structured way to set up actions/accels/etc and use/present them in various ways. Anyway, that's quite beyond this bug's topic, but perhaps some food for thought.
> but it'll save me a lot of maintenance at the cost of the GTK+ team maintaining a behemoth...
Yup, something on that scale, and likely prone to different users all wanting slightly different things and debating it forever, may just never fit. I was just noting that it's the general kind of thing that people recurrently want - regardless of whether they want compatible things or care which library does it.
-- 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/gtk/issues/903.