GNOME Bugzilla – Bug 72375
Way to turn off accelerators / mnemnics?
Last modified: 2007-02-05 14:16:25 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:
KeyHash change made it:
Possible solution is:
Or alternatively, make the activation/keyhash APIs
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
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.
Created attachment 66266 [details] [review]
Dynamically show/hide keyboard shortcuts
Created attachment 66267 [details] [review]
Disable mnemonics and accelerators
depends on previous patch
Created attachment 66268 [details]
Created attachment 81199 [details] [review]
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).
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.
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
Created attachment 81257 [details] [review]
- removes hildon prefixes
- adds two properties "gtk-enable-mnemonics" and "gtk-enable-accelerators"
Created attachment 81258 [details] [review]
fix typo in previous patch
Looks good to me.
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)
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:)
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...
Going by the examples of gtk-button-images, gtk-menu-images or gtk-split-cursor,
we could just go with
Fine with me, but I think it should be "gtk-accels", to
be consistent with other properties.
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-enabled: would be fine, but I don't think it's
better than gtk-enable-accelerators.
Fixed in SVN:
2007-02-05 Michael Natterer <firstname.lastname@example.org>
* 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.