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 72375 - Way to turn off accelerators / mnemnics?
Way to turn off accelerators / mnemnics?
Product: gtk+
Classification: Platform
Component: Widget: Other
Other All
: Normal enhancement
: Medium API
Assigned To: gtk-bugs
Depends on:
Reported: 2002-02-23 21:50 UTC by Havoc Pennington
Modified: 2007-02-05 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---

Dynamically show/hide keyboard shortcuts (5.26 KB, patch)
2006-05-26 11:20 UTC, Tommi Komulainen
none Details | Review
Disable mnemonics and accelerators (3.58 KB, patch)
2006-05-26 11:21 UTC, Tommi Komulainen
none Details | Review
test (3.38 KB, text/plain)
2006-05-26 11:21 UTC, Tommi Komulainen
Combined patch (6.34 KB, patch)
2007-01-25 15:36 UTC, Michael Natterer
needs-work Details | Review
updated patch (7.91 KB, patch)
2007-01-26 09:36 UTC, Michael Natterer
none Details | Review
fix typo in previous patch (7.91 KB, patch)
2007-01-26 09:48 UTC, Michael Natterer
none Details | Review
forgot to upload latest version (8.18 KB, patch)
2007-01-29 11:00 UTC, Michael Natterer
committed Details | Review

Description Havoc Pennington 2002-02-23 21:50:50 UTC
KeyHash just broke my profterm keybindings plan - I needed to override
GtkWindow::key_press_event and do things a bit differently (optionally
disable mnemonics and/or accelerators), but now there is no public way
to do the mnemonics/accelerators since it involves all this new
private key hash stuff and _gtk_window_activate_key().

All I can do now is offer an option to	disable all
mnemonics/accelerators (no one will use this since Alt+F
etc. interferes with too many terminal apps). So that ruins the plan
to make the change-tab etc. shortcuts be accelerators, instead they
have to just be a key_press_event hardcoded hack, which means they
won't i18n correctly and I don't know how I'm going to integrate them
with the accelerator displayed next to the menu item.

window::key_press used to just be:


My plan was to override with:

  if (mnemonics_enabled)
  if (accels_enabled)


KeyHash change made it:

Possible solution is:


Or alternatively, make the activation/keyhash APIs 
Comment 1 Owen Taylor 2002-02-23 22:14:28 UTC
Disabling mnemonic activation without disabling menomonic
display (and same for accelerators) seems entirely broken.

I guess a global flag to toggle mnemonics might go along
with XP style mnemonics-appear-on-alt handling. 

Accels when turned off should probably appear disabled rather
than disappear.
Comment 2 Tommi Komulainen 2006-05-26 11:19:03 UTC
I've been considering a patch much like this for the maemo platform. In our case the use case is closely related to the presence of a 'real' keyboard. If there is no keyboard present it makes no sense to display the keyboard shortcuts since you wouldn't be able to activate them anyway. In this scenario disabling activation is less important, but I have a separate patch for such effect.
Comment 3 Tommi Komulainen 2006-05-26 11:20:06 UTC
Created attachment 66266 [details] [review]
Dynamically show/hide keyboard shortcuts
Comment 4 Tommi Komulainen 2006-05-26 11:21:08 UTC
Created attachment 66267 [details] [review]
Disable mnemonics and accelerators

depends on previous patch
Comment 5 Tommi Komulainen 2006-05-26 11:21:45 UTC
Created attachment 66268 [details]
Comment 6 Michael Natterer 2007-01-25 15:36:41 UTC
Created attachment 81199 [details] [review]
Combined patch

Update combines the two patches, applies cleanly against trunk,
fixes iterating the toplevels (only iterate toplevels on the setting's
screen), and doesn't treat signal handler IDs as guint (they are gulong).
Comment 7 Richard Hult 2007-01-25 16:03:17 UTC
It could make sense to separate mnemonics from shortcuts, and have two settings. It would be really usable for the OSX port, it would enable shortcuts and disable mnemonics.
Comment 8 Matthias Clasen 2007-01-25 18:18:23 UTC
Looks fine to me in general. Comments:

1) longer-term, we may want to centralize the iterate-over-all-widgets loops
  that we have in several places

2) you should remove the hildon prefix

3) I agree with Richard that we should support what OS X needs from this feature
Comment 9 Michael Natterer 2007-01-26 09:36:02 UTC
Created attachment 81257 [details] [review]
updated patch

- removes hildon prefixes
- adds two properties "gtk-enable-mnemonics" and "gtk-enable-accelerators"
- cleanup
Comment 10 Michael Natterer 2007-01-26 09:48:38 UTC
Created attachment 81258 [details] [review]
fix typo in previous patch
Comment 11 Matthias Clasen 2007-01-26 16:17:46 UTC
Looks good to me.
Comment 12 Michael Natterer 2007-01-29 11:00:19 UTC
Created attachment 81415 [details] [review]
forgot to upload latest version

- renames property to gtk-enable-accels to be consistent with other properties
- adds property docs (a bit short perhaps)
Comment 13 Tim Janik 2007-01-30 11:29:14 UTC
the logic of the patch looks pretty good, but i think we should consider the actual property names. usually, gtk uses
  <gtk> - <entity> - <verb-or-attribute>*, and not
  <gtk> - <verb> - <entity>.
allthough GtkSetting properties already became a bit inconsistent over time:
and there's also a recent one that uses "enable" already:

before we move on to use verbs instead of entities for a random selection of new properties, i'd like to see these questions answered:
1) do we really want to claim <gtk>-<verb> namespaces? especially in english,
  verbs are not unliekly to alias nouns ("to show" vs. "the show"), so future
  clashes are not unlikely.
2) which verb namespaces should be claimed? "enable"? "disable" also?
  and then, shouldn't the current gtk-show properties be renamed to gtk-enable?
3) when should <gtk>-<verb> be used instead of <gtk>-<entity>?
  e.g. what's a compelling argument for ::gtk-touchscreen-mode vs.

note that the current use of gtk-show and gtk-enable by 3 properties can easily be fixed backwards compatibly, once we've reached a conclusion on the naming here.

for the two properties at hand, suitable alternative names could be ::gtk-mnemonics-activatable and ::gtk-accels-activatable.

comments apprechiated. (putting Owen as native speaker on CC:)
Comment 14 Michael Natterer 2007-01-30 11:41:48 UTC
I agree that the gtk-verb-entity inconsistency shouldn't have been
introduced, however ::gtk-mnemonics-activatable and ::gtk-accels-activatable
don't really make the point. The patch disables mnemonics and accels
alltogether (visually and logically), so it's not only their activation
that is switched off.

Following the logic of other boolean settings properties, it should probably
simply be "gtk-mnemonics" and "gtk-accels" but that just sounds too bad
to be used.

I'm open for suggestions here...
Comment 15 Matthias Clasen 2007-01-30 14:17:05 UTC
Going by the examples of gtk-button-images, gtk-menu-images or gtk-split-cursor,
we could just  go with

Comment 16 Michael Natterer 2007-02-03 20:21:39 UTC
Fine with me, but I think it should be "gtk-accels", to
be consistent with other properties.
Comment 17 Owen Taylor 2007-02-03 20:30:33 UTC
My feeling here is that we don't have enough GTK+ settings to make 
some sort of hierarchical namespacing worthwhile.

 gtk-enable-accelerators (or accels if you so prefer)

seems like a fine me. 

 gtk-accelerators: Unclear what it is
 gtk-accelerators-activatable: weird

gtk-accelerators-enabled: would be fine, but I don't think it's
better than gtk-enable-accelerators.
Comment 18 Michael Natterer 2007-02-05 14:16:25 UTC
Fixed in SVN:

2007-02-05  Michael Natterer  <>

	* gtk/gtksettings.c: add new boolean settings gtk-enable-accels
	and gtk-enable-mnemonics which enable/disable accelerators and
	mnemonics (bug #72375, based on a patch from Tommi Komulainen).

	* gtk/gtkwindow.c (gtk_window_activate_key)
	* gtk/gtkmenushell.c (gtk_menu_shell_key_press): don't invoke them
	if the resp. setting is FALSE.

	* gtk/gtkaccellabel.c (gtk_accel_label_refetch)
	* gtk/gtklabel.c (gtk_label_set_pattern_internal): don't display
	them if the setting is FALSE.

	* gtk/gtklabel.c: added signal connection to the screen's settings
	object and traverse all widgets on the screen when the setting
	changes. It's slightly ugly to also update GtkAccelLabels here,
	but less ugly than connecting and traversing all widgets twice.