After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 111438 - Widget should be recieve key event before mnemonics and accelerators
Widget should be recieve key event before mnemonics and accelerators
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
2.2.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-04-23 16:47 UTC by TOKUNAGA Hiroyuki
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
give priority to focused widget over mnemonics (751 bytes, patch)
2003-04-23 16:49 UTC, TOKUNAGA Hiroyuki
none Details | Review

Description TOKUNAGA Hiroyuki 2003-04-23 16:47:13 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 ;-)
Comment 1 TOKUNAGA Hiroyuki 2003-04-23 16:49:01 UTC
Created attachment 15944 [details] [review]
give priority to focused widget over mnemonics
Comment 2 Hidetoshi Tajima 2003-05-14 00:18:13 UTC
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 
Comment 3 Owen Taylor 2003-05-20 03:31:27 UTC
* 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.
Comment 4 Yusuke Tabata 2003-05-22 15:33:55 UTC
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.
Comment 5 ynakai 2003-08-28 05:27:15 UTC
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.
Comment 6 Takuro Ashie 2003-08-28 17:04:53 UTC
> 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.
Comment 7 Owen Taylor 2003-09-02 21:43:08 UTC
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.
Comment 8 ynakai 2003-09-04 06:33:26 UTC
#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.
Comment 9 TOKUNAGA Hiroyuki 2003-09-04 20:32:23 UTC
 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?
Comment 10 TOKUNAGA Hiroyuki 2003-09-06 02:27:55 UTC
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.
Comment 11 Philip Langdale 2003-09-06 17:42:13 UTC
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.