After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 727134 - Menu shortcut keys can't be disabled
Menu shortcut keys can't be disabled
Status: RESOLVED DUPLICATE of bug 728121
Product: gnome-terminal
Classification: Core
Component: Keybindings
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-27 05:37 UTC by Egmont Koblinger
Modified: 2014-04-14 16:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix (535 bytes, patch)
2014-03-27 17:03 UTC, Egmont Koblinger
rejected Details | Review

Description Egmont Koblinger 2014-03-27 05:37:47 UTC
Preferences -> Shortcuts -> Help -> Contents is set to "Disabled", yet F1 brings up the help, rather than emitting the proper escape sequence.

Setting the shortcut to F1 and then disabling doesn't help.

Setting the shortcut to something else and then disabling doesn't help either.

Setting the shortcut to something else (e.g. F2), then setting it to F1, then disabling helps - for the lifetime of g-t. Quit and restart g-t and it brings up the help again.
Comment 2 Egmont Koblinger 2014-03-27 17:03:43 UTC
Created attachment 273099 [details] [review]
fix

It's the hardcoded menu shortcut that causes the problem.
Comment 3 Egmont Koblinger 2014-03-27 17:34:43 UTC
... Which brings us to a more generic problem, not specific to Help.

In the application menu, many entries have a corresponding shortcut key (e.g. F1 for help, Shift+Ctrl+C/V for copy-paste, Ctrl+± for zoom, Shift+Ctrl+F for find, etc...). These keys seem to be modifiable in Preferences->Shortcuts, but in fact you can only define an additional key to the hardcoded default (and hence have two shortcuts for each action), but you can't disable the default.

Others (e.g. F11 for fullscreen, Alt+n for switching to the nth tab etc...) are not defined as menu shortcut. So these can be disabled, although it's not a nice user experience that the menu doesn't inform you about these shortcuts.

A different code path is executed depending on weather it's a custom hotkey or the hardcoded menu hotkey, e.g. action_help_cb() vs. help_contents_callback().

Probably the right solution is to remove all the hardcoded menu shortcuts, and make the user-defined ones dynamically propagate into the menus. The menu widget would take care of performing the desired action, the custom hotkey system would only need to do so for those that have no menu entry.

Apparently this is exactly what we used to have prior to the above mentioned commit. Seems like it was a broken-by-design change??
Comment 4 Debarshi Ray 2014-04-14 16:17:01 UTC

*** This bug has been marked as a duplicate of bug 728121 ***