GNOME Bugzilla – Bug 160431
it's too easy to accidentally bind normal keys to menu items with unintended consequences
Last modified: 2007-11-06 21:27:53 UTC
1. Type Alt-F Q, expecting to quit (since this would work in many applications). 2. You don't quit. No big deal. 3. Next time you're typing something with a q in it, a new window pops up suddenly. 4. Realize that what you did when you typed Alf-F Q was bind "new window" to "q" I love the ease and intuitiveness with which you can rebind keys, so I'm not advocating for removing this feature. However, perhaps a simple check could be run to make sure that you're not binding to an unmodified key like "a" or "q". I see the immediate objection that users will want to bind to unmodified special keys, like function keys -- so perhaps an exception could be made for them. Finally, in the rare case that users actually *do* want to bind a menu item to a key like "q", a dialog should be displayed explaining what you're doing and confirming that you want to do it. Otherwise, the wonderfully easy-to-use, intuitive, non-threatening epiphany can very quickly seem erratic and bizarre as the fumbling user binds random keys to random menu items by accident. (I've done this more than once already!)
Yes it is a problem, but it's in GTK, Epiphany can do nothing about it (as far as I know).
Gtk+ bug 120034 has a bit of discussion about this (not exactly this, though). Why not simply disable accel editing in gconf?
bug 120034 seems rather different. The reason not to disable accel editing is that I like accel editing. I just think that programs that involve text editing should not allow assigning unmodified keys -- otherwise users can inadvertently assign a key like "b" and not know what they've done. On the GTK level, perhaps there should be more user feedback when they've assigned a key to make it clear that's what they've done. On an epiphany level (and many other apps), perhaps we need to disable the assignment of all unmodified keys. I don't know if this is do-able with the current GTK API, in which case it might be a bug for them. Obviously this shouldn't be an across-the-board decision since there are plenty of apps where having a single key launch a menu item makes sense (such as in an image viewer). Tom
This works the same in all gtk+ apps when can_change_accel is activated. Moving to gtk+.
The main use case for accel editing is the gimp, where assignment of unmodified keys is very useful. In general, interactive changing of keys is off by default for a reason. It's confusing; if you turn it on, you are going to have to deal with that. Bug 120034 discusses adding a non-in-place menu editor.
Owen: so are you suggesting that apps like epiphany should turn off interactive changing of keys entirely? Or is there a way for them to implement interactive changing of keys that limits what the user can assign?
What Owen refers to is that the gconf key /desktop/gnome/interface/can_change_accels globally controls interactive changing of keys, and it defaults to off.
(In reply to comment #5) > The main use case for accel editing is the gimp, where assignment of > unmodified keys is very useful. > > In general, interactive changing of keys is off by default for a reason. > It's confusing; if you turn it on, you are going to have to deal with > that. So, in conclusion, in the normal case the user would want to turn changing shortcuts on in the gimp, and off everywhere else. This does not seem possible at the moment. I'm considering getting this bug reopened.
In the GIMP: Preferences/Interface/Use Dynamic Keyboard Shortcuts