Bug 162453 - Pressing F1 while hovering a menu entry does not work in gtk3
Summary: Pressing F1 while hovering a menu entry does not work in gtk3
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shortcuts-Accelerators GTK3 Help
  Show dependency treegraph
 
Reported: 2024-08-13 16:04 UTC by Michael Weghorn
Modified: 2024-08-13 16:11 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2024-08-13 16:04:45 UTC
Split out from tdf#156376 which was originally for gtk3 and kf5, quoting from there:

(Rafael Lima in tdf#156376 from comment #0)
> On Windows, if you hover over a menu entry (f.i. Tools - Spelling) and then
> press F1 while the mouse is over the entry, the corresponding help page will
> open.
> 
> This also works with "gen" on Linux... I can't tell about MacOS.
> 
> However it does not with with gtk3 (...).

See that bug for more details/background.
Comment 1 Michael Weghorn 2024-08-13 16:06:43 UTC
Quoting Caolán's tdf#156376 comment #11:

> I can't comment on the kf5 menus, but there are two types of menus in gtk,
> the various arbitrary menus like context menus and then the other types of
> menus which belong to the toplevel menubar. For the toplevel menubar we
> provide an fairly abstract menumodel to gtk.
> https://docs.gtk.org/gio/class.MenuModel.html and
> https://developer-old.gnome.org/gio/stable/GMenuModel.html 
> 
> As far as I know there is no field/support in that MenuModel which supports
> the concept of help for a menu entry and no straightforward way to access
> the underlying widgets that implement the menu in order to hook into some
> F1/help activation (the menubar and menus might not even be in the
> application, the Unity thing of a macOS-like shared desktop menubar might
> have fallen out of favor but the apis we use are theoretically supportive of
> that so the menumodel might not even get consumed by a traditional
> menubar+menu.
> 
> I could see that hacking the arbitrary menus might be doable to get help in
> there, but I never could see how to do it for the toplevel menubar+menus.