The option only affects keyboard shortcuts displayed in context menus (like Ctrl+Something), see bug 74377

Let's ask UX about the naming

Ok, but this setting has no effect on context menus either. As far as I can see the behaviour of accelerators (shortcuts) in context menus is consistent with the same in the main menu and on windows and on linux with vcl=x11 they are shown all the time - this is the behaviour I am trying to get on KDE but with vcl=kf5 they are shown only after alt is pressed. And with vcl=gtk3 they are shown about half a second after alt is pressed - this is really annoying.

(In reply to lvm from comment #2)
> Ok, but this setting has no effect on context menus either. As far as I can
> see the behaviour of accelerators (shortcuts) in context menus is consistent
> with the same in the main menu and on windows and on linux with vcl=x11 they
> are shown all the time - this is the behaviour I am trying to get on KDE but
> with vcl=kf5 they are shown only after alt is pressed. And with vcl=gtk3
> they are shown about half a second after alt is pressed - this is really
> annoying.

It's not about accelerators, but the hints for keyboard shortcuts.

The accelerator behaviour comes from the operating system and is respected.

So it does and changing the global default setting fixed the issue. Closing.

Let's keep this open as the label is a UX issue

I expect with Shortcuts=Hide all descriptive text like "Save (Ctrl+S)" to be gone so the label would be just "Save". It's not happening for gen, gtk3, gtk4, kf5, and qt6 and the "Ctrl+S" hint remain always visible.

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ef1ffdc3087853ac94847d0c8fec8717feb62224
CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

UX-wise I see no issue with "Shortcut", at least after reading the online help. 

And btw. the mnemonic is always visible for gen and qt6.

(In reply to Heiko Tietze from comment #7)
> I expect with Shortcuts=Hide all descriptive text like "Save (Ctrl+S)" to be
> gone so the label would be just "Save". It's not happening for gen, gtk3,
> gtk4, kf5, and qt6 and the "Ctrl+S" hint remain always visible.

The option only affects context menus, not menus. So the question here for UX is: do we rename it to "Shortcuts in context menus" or what?

On  kf5/7.5.1.2 this option works but affects only context right-click menus, not main menus, and judging by the comment #1 this is by design. Extending it to main menu could be a good idea.

Also I am not quite clear as to what "Automatic" setting is supposed to do. As far as I can tell it has the same effect as "Show" and therefore redundant.

(In reply to Buovjaga from comment #8)
> The option only affects context menus...

I see, a ridiculous function again. Renaming it to something longer breaks the UI (downside of the label left of the control layout is that we need to aim for string with similar length). My take: move this option and the menu icons into the expert settings. Or make it work for the main menu too.

This used to be called "Shortcuts in context menus:" before

commit 342a759dae8c58f2256e5aa92e1d27fd4a3601c7
Date:   Mon Nov 11 22:52:37 2019 +0100

    tdf#128721 Options -> View Dialog update


and "Shortcuts in context menus:" was added originally with

commit 74fd959945dbbfbc3dcc331a08ff8fc7c6410295
Date:   Wed Sep 14 02:02:38 2016 +0300

    tdf#74377 Keyboard shortcuts for context menus

so its all doing what it was intended to do, but got relabeled to suggest something more general along the way.

I'm in favour of making less of our horde of options visible to the user though

The assumption while implementing Bug 74377 was that the main menu supposed to always show the shortcuts, as is the case in any other app and any OS, and there is no use in allowing to disable this. This is unlike context menus which e.g. shouldn't have shortcuts according to Apple's HIG, and used to not have shortcuts back in gtk2 (and early gtk3) days.

(In reply to lvm from comment #9)
> Also I am not quite clear as to what "Automatic" setting is supposed to do.
> As far as I can tell it has the same effect as "Show" and therefore
> redundant.
Automatic means "follow the current platform default", i.e. it defaults to "Hide" for macOS and gtk3.

yeah, which is desirable from my POV. I think just following the DE out of the box and not offer the option in dialogs to change it (but leave it configurable via export config) is the easiest thing to do

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/770eea32b68a95e493a86a97eba5003c46ed736b

tdf#152898 remove "show context menu shortcuts" from options page

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Caolán McNamara from comment #13)
> yeah, which is desirable from my POV. I think just following the DE out of
> the box and not offer the option in dialogs to change it (but leave it
> configurable via export config) is the easiest thing to do

At least one of the gtk versions hide the icon option and I wonder if the frame remains visible in this case without any content.

The frame "frame3" is gone completely now.

I mentioned it as deprecated in the release notes. Not sure if something should be said about the GTK icons though?

https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F7.6&type=revision&diff=683666&oldid=682844

Note that we still have a leftover UI hint in https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Common.xcs?r=3d8b7fd3#2740