GNOME Bugzilla – Bug 111438
Widget should be recieve key event before mnemonics and accelerators
Last modified: 2004-12-22 21:47:04 UTC
In Gtk+ 2.x, key event progresses as follows. gtk window -> check mnemonics and accelerators -> focused widgets However, I think that priority should be given to focused widget over mnemonics. Because in some cases, I wants to process a key event by widget. You may say that such design is not good, but for Input Method, I think it is better than now. I think this problem similar to Bug 90082 (Input Methods need to receive any key evnet), but I also think that these are different in the following points. 1. If applied my patch, it still depends on widget that whether immodule is treated appropriately or not. 2. Bug 90082's patch is giving special treatment to XIM. So it's not solution for other immodule. 3. This attached patch is very short ;-)
Created attachment 15944 [details] [review] give priority to focused widget over mnemonics
I'm not sure if this bug really is the same as bug 90082, but at least the proposed patch cannot always fix 90082, A widget to receive key events and hence process them for mnemonics can be different from the widget which input method's focusing on. Even applying this patch, gedit must take F10 always to open a file menu, even when the input method is active and expects to filter key events. a
* Making such a change would break compatibility with existing applications * Making such a change is not compatible with the XEMBED spec for interapplication embedding. * Properly designed applications must avoid conflicts. One compelling reason that when there is a conflict accelerators should take precedence is visibility: - Mnemonics and accelerators are displayed to the user, all users expect them to work - Widget key bindings are invisible and often only known to a small group of experienced useres.
From compatibility point of view, gtk+2 should give higher property to input methods than mnemonics and accelerators. With most of Japanese XIM clients and even with Japanese Windows' MS-IME, typing ctrl-H deletes backward preedit char. Not to open History or Help window. (Input methods does not handle the event if there are no preedit string. So History of Help window will open.) We recently submitted same fix to Qt and the patch got applied.
This is an important issue and I don't think this is RESOLVED. The current GTK+2 implementation breaks input methods' compatibility/consistancy/culture. XIM doesn't, IIIMF doesn't, Qt doesn't, but GTK+2 do. The basic idea of multi-byte input method is, stealing all inputs from the keyboard, selecting correct multibyte combination with some additional info from the user, and pass the result to the application as if that multibytes are just direct inputs from keyboard. So anyway, GTK+ must let all input methods catch keyboard events first. Otherwise, trying Japanese clause length change (Ctrl+O) causes an unexpected file-open dialog pop-up, user will get panic, and any effort to develop Japanese immodule will not make sense.
> This is an important issue and I don't think this is RESOLVED. I think so too, and I think it's not only Japanese problem, but also on English environment. For example, some GTK+2 applications (such as Galeon) can't accept Emacs-like key binding because of this problem. > XIM doesn't, IIIMF doesn't, Qt doesn't, but GTK+2 do. In addition to this, MS-Windows doesn't, Mac doesn't, Gtk+1 doesn't, but GTK+2 do.
I'd love evidence that the Macintosh or Qt or Windows process menu accelerators before widget key bindings. That's different from whether *input method* key bindings take precendence over menu accelerators. See bug 90082 for the specific question of input methods. Note that making either input method key bindings or all widget key bindings take precendence have similar problems with XEMBED.
#90082 bug looks like just trying to fix with X-dependent codes. So that will not take effect for the development of the generic GTK+2 immodules, which might be used for frame buffer, tty, or other possible X independent GTK+2 environment. And I cannot find any keyword 'input method' in the XEMBED specification you co-authored. If it didn't consider the CJK input methods, that spec would be broken and as same as nothing. I'm not just saying 'let's use the patch #2'. GTK+2 immodule needs to provide the way for immodule to get mnemonic, anyway. Mac provides it, Win does, and other sane products might do.
I'm thinking this bug report isn't appropriate. What I want to fix is a problem about input method, and "Widget should be recieve key event" was an idea to solve. But now I've understood widget should not recieve key event before accelerators,and the problem about input method should solve by other solution. There are some reasons. 1. XEMBED say menu accelerators should recieve key event before widget. 2. behavior of exsisting applications is accelerators -> widget key bindings. In other words, backyard compatibility. 3. This is the biggest, accelerators -> widget is more useful than widget-> accelerators. So, though gtk+ has a problem about input method, using this bug #111438 to solve the problem is not good, I think. We should create a new bug report or move to Bug 90082. Which is better action?
Oh, I mistook that Bug 90082 was XIM specific... But, 90082 is NOT XIM specific bug report, so moving to Bug 90082 is the best way here, I think.
Given that this bug has been marked WONTFIX, could the powers that be provide a way for me to do the following (which was possible in gtk+ 1.2 ). For galeon, there are some key events that the embeded mozilla widget handles by itself without any work on our part. An example of this is that ESC should end a "find-as-you-type" search. However, we need to bind ESC to the Stop-Page-Load action which we do. However, this means mozilla never sees the ESC key event and cannot act on it. This obnoxious behaviour occurs even if the Stop-Page-Load action is disabled (when a page isn't loading); the key event is still eaten by the accel system. I can see no way around this. GtkAccel is written in such a way that toggling an Accel is virtually impossible, so any enlightenment that could come my way would be very much appreciated. I still fail to see why widgets can't see the events. Even if the Accel sees the event first, it should still be passed on and not consumed.