GNOME Bugzilla – Bug 102212
Keys in textview key themes still propagate to the menu.
Last modified: 2004-12-22 21:47:04 UTC
If I put this: gtk-key-theme-name = "Emacs" in my ~/.gtkrc-2.0, then when composing a reply I should be able to use ctrl-a and ctrl-e to navigate a line of text and ctrl-w to delete a word of text. The ctrl-a does in fact work correctly, but the ctrl-e and ctrl-w are being intercepted by the menu instead. (I.e., the pop up an editor and close the message composition window, respectively.) If I edit message-window.c and change the menu controls to specify NULL rather than "<control>E" and recompile, then that fixes the ctrl-e, so I know the key-theme is working correctly. However, to fix the ctrl-w it is not sufficient to change "<control>W" to NULL; you have to change it to another value such as "<control>Q". (The ctrl-w accelerator still shows up on the menu even after I have changed it to NULL and recompiled; I have not figured out where it is picking it up. But if I change it to "<control>Q" it does show up as ctrl-q in the menu, and ctrl-w works as expected for the "Emacs" key-theme.) I haven't started looking at GTK+ 2 yet, so I don't know whether the problem is caused by having the menu grab the keys before the textview widget does, or whether the textview widget is passing the value on even when the key-theme says it should be processed by the widget. (If the problem is in GTK+ 2 rather than in Pan please kick this upstairs, because it will be a major issue when people start wanting to write their own key themes.)
As I understand it, the gtk2 menu accelerators are deisgned to work regardless of what child widget has focus. I don't know what the policy should be when the child textview's keystrokes are in conflict with standard menu accelerators.
Looking at gtk_propagate_event() and gtk_window_key_press_event(), mnemonics and accelerators on the toplevel window take priority over focus widget keybindings which in turn take priority over toplevel keybindings. So it seems to be intended behaviour that the C-w accelerator shadows the C-w keybinding of the Emacs theme.
> Looking at gtk_propagate_event() and gtk_window_key_press_event(), > mnemonics and accelerators on the toplevel window take priority over > focus widget keybindings which in turn take priority over toplevel > keybindings. > So it seems to be intended behaviour that the C-w accelerator shadows > the C-w keybinding of the Emacs theme. I haven't started programming under GTK+ 2 yet, but I thought under GTK 1 the _innermost_ active widget got the first grab at a keystroke or other event and had the choice of processing it, passing it upward, or doing both. If what you describe is in fact the implemented behavior you might want to ping the GTK+ folk on this, because ISTM that it will cause people a lot of problems and annoyance in a lot of applications other than Pan.
> If what you describe is in fact the implemented behavior you might > want to ping the GTK+ folk on this, because ISTM that it will cause > people a lot of problems and annoyance in a lot of applications other > than Pan. This ticket has already been bounced from Pan's list to gtk's list, so they will be aware of it when they look at bugzilla.
Accelerators take priority, that's how it works.