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: activate_mnemonics(); activate_accels(); activate_focus_widget(); My plan was to override with: if (mnemonics_enabled) activate_mnemonics(); if (accels_enabled) activate_accels(); activate_focus_widget(); KeyHash change made it: private_activate_stuff_code(); activate_focus_widget(); Possible solution is: gtk_window_set_mnemonics_enabled() gtk_window_set_accelerators_enabled() Or alternatively, make the activation/keyhash APIs public.
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.
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] test
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).
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] updated patch - removes hildon prefixes - adds two properties "gtk-enable-mnemonics" and "gtk-enable-accelerators" - cleanup
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: ::gtk-show-input-method-menu ::gtk-show-unicode-menu and there's also a recent one that uses "enable" already: ::gtk-enable-animations 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. ::gtk-enable-touchscreens? 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 gtk-accelerators gtk-mnemonics
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-activatable: weird 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 <mitch@imendio.com> * 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.