Wnn also has the same issue as ATOK. In Wnn, the input mode
is changed by typing F1 key. But gnome-help start...
In CDE Environment, if Wnn is active, dthelpview does not start by
typing F1 key and the input mode is changed.

 Steps to reproduce:
  0. Setup Wnn6(execute /usr/openwin/bin/wnn6setup).
  1. Log in Solaris+GNOME2 env. (Locale is 'ja')
  2. Start gedit.
  3. Type [Ctrl+Space] and start Wnn6.
     IM status is displayed in the workspace.
  4. Type [F1] in gedit's input field.
     But the input mode is not changed and gnome-help start...

This problem is very inconvenient for users and this behavior
is not compatible in Input Methods.

Bumping priority back down because I have no idea how we can
fix this ... best idea so far is that GtkIMContextXIM could
connect to ::key-press-event on the toplevel window on
focus-in and intercept key events until focus out, but that
won't work for things like widgets embedded within a 
Plug/Socket combination.

The fact that accelerators are prioritized above keyboard
shortcuts for widgets is partly done for compatibility with
Qt to allow inter-toolkit embedding, it can't just be
changed without taking that into account.

(Plus, I think prioritizing menu accelerators above widget
shortcuts is right from a useability point of view.)

The basic problem here, like any problem with key shortcuts, is
that the shortcuts haven't been properly coordinated.
Why should Japanese users be unable to access their menus
or Help applicaitons via the keyboard? Not that it's 
necessarily practical to say "please  learn a new set
of input method bindings".

Add gnome2-g11n-qa@sun.com to Cc.

Moving input method related bugs to input-methods component

There are some key conflicts with Korean Input Method.

Ctrl + w which converts Hanguel to Hanja in ko preedit mode. 
Ctrl + x which enables hexa value input for EUC-KR.

Ctrl + w conflicts with Ctrl + w for close window in GTK.
Ctrl + x conflicts with Ctrl + x for cut into clipboard.

GTK+ is getting key input before the input server disabling those
functionality.
The above bugzilla ID is also edited.

Putting it on the 'future' milestone at least until there are
concrete suggestions about how to fix.

I agree with the original comment that IMs should get a chance at
keypresses before anything else (including user key-press-event
handlers).  The current state of affairs makes GtkEditables and
GtkTextView very difficult to work with with XIM.

For instance, any user application wanting to take some sort of action
on <space> or <enter> could very well interfere with kinput2 (a
Japanese XIM server) preventing it from doing its business properly;
to see this, add a key-press-event for GDK_Return which returns TRUE
(event handled) and attempt to commit text to an entry through kinput2
and XIM; you will never be able to commit the text to the entry, it
will remain in a perpetual pre-edit state.

To complicate matters farther, any non-XIM entered text (for instance,
latin characters) already present in the entry will appear normally
should the associated GtkTextBuffer (for a GtkTextView) or GtkEntry
contents be queried, but the XIM preedit text is not available.  In
addition, I have been unable to find a reliable method of determining
if such preedit information even exists from application space.

In the meantime I am going to attempt to subclass GtkTextView, but
this is not, I think, something that should be solved in every
application individually.

cleaning up dead alias. Sorry for the spam.

Owen, 

I tried gtk_key_snooper_install() and
gtk_key_snooper_remove() from GtkIMContext's focus-in and focus-out.
This seems to work well
as far as I've briefly tested with gedit and 
gnome-terminal. Is there any risk by using them
to fix this issue?

Hmm, it looks like snooper is prepared for Atk, so
input method is not allowed to use it?

 - Using KeySnooper is a probably a bad idea; it's meant as
   a way of bypassing normal event handling. You should
   be able to get an equivalent effect by connecting to
   the key-press-event signal on the toplevel.

 - Note that any method involve intercepting key events on
   the toplevel will not work in the context of embedding,
   as done with Bonobo.

I think the only real long term solution is to figure out 
a convention such that input method key bindings don't
interfere with other keybindings. Otherwise, we are just
in a broken situation ... some keybindings are getting
lost.

Not indending to just add noise to this thread, I want to say that it
concerns me that Gtk2 seems to want to treat keystrokes that may be
directed to XIM as "normal" keystrokes, while I am inclined to think
that they are in fact something else entirely.

From what I have seen of the signal propagation in Gtk2 and the
discussion here, I wonder if some sort of "pre-key-press-event" that
wends its way through before the key-press-event and has the power to
grab the keypress and prevent the key-press-event from ever happening
is not in order.  (I realize that stopping an as-yet-nonexistent event
is not in the Gtk2 event model, this is just an idea.)

The high point seems to me to be that keypresses that XIM needs are
*not* normal keypresses; they are a portion of an "uber-keypress" of
sorts that XIM will send when it flushes its buffer.  Treating it as
anything else is, I think, likely to break on some XIM system
somewhere.  Avoiding XIM keybindings is not a valid solution, as there
are N different XIM systems out there with N different solutions;
mandating an XIM keybinding set for use with Gtk2 is also not a
solution, I don't think, as that is akin to asking e.g. English
speakers to switch to dvorak just to use Gtk2, or Germans to kindly
avoid the usage of umlauts in Gtk2 applications.

Well, I've been looking for a way to bypass normal
key-press handling and let XIM filter all keyevents firsr, 
so a keysnooper is, since I happend to find it, seen as if
it was prepared for the XIM.

XIM I'm referring here usualy have explicit turn-on ad
turn-off modes. In the turn-off mode, XIM does not filter most of
keyevents except a few keys to switch to turn-on mode(e.g. Kinput's
Shift-space), so almost all of gtk+ application's keybindings should
be stll effective. In the turn-om mode, XIM filters all key events
first, so all XIM's keybindings are effective in turn, and some of
applications keybindings are
still valid if they are not filtered by the XIM.

I don't say this is the best solution among what can be, 
but it has been widely accepted by many different XIM client
applications and server components and their Asian and 
Japanese users in the past 10+ years.

Hence, I believe, allowing XIMs to filter all key events
in the turn-on mode won't be fatal for GTK+ application's
keybindings and would not bring much confisions for Asian
and Japanese users - who are accustommed to the way
to get along with XIM's and each app's keybidings.

BTW, I tried to set key_press_event signal on
the toplevel window (this from a client
window set to the context), but I could not
get keys for the accelerators yet.

  toplevel_gdk = context_xim->client_window;
  screen = gdk_drawable_get_screen (toplevel_gdk);
  root_window = gdk_screen_get_root_window (screen);

  while (TRUE)
    {
      GdkWindow *parent = gdk_window_get_parent (toplevel_gdk);
      if (parent == root_window)
	break;
      else
	toplevel_gdk = parent;
    }

  gdk_window_get_user_data (toplevel_gdk, (gpointer *)&toplevel);
  if (toplevel)
    signal_id = gtk_signal_connect (GTK_OBJECT (toplevel),
"key_press_event",
				    GTK_SIGNAL_FUNC (gtk_im_key_press_cb), context);

Do you see anything wrong with the code above?
I do this in a xim-focus-in handler.

Created attachment 11923 [details] [review]
a sample patch to use a key-snooper to let XIM filter key events

Created attachment 11926 [details] [review]
2nd patch

Created attachment 12812 [details] [review]
needed to make a snooper static

Created attachment 14947 [details] [review]
3rd patch - snooper should be only removed when the associated GtkIMContext is finalized or unfocused

After all, I realize using key snoopers isn't 
good. Apps would crash when there're multiple 
text widgets, and a focused widget which has 
a snooper installed, is killed without having a 
chance to remove it.

I'd then want a right fix, but, putting key_press 
signal to the toplevel widget on focus_in does not
seem to work. Even when it's installed, each widget's key-press signal
is executed first and there is no chance to come to GtkIM's
filter_keypress. [e.g. "F10" is consumed by gtkmenubar's key_press
handler as it is "gtk-menu-bar-accel".]
Perhaps, I'm doing things wrong. Attaching a
tem patch. Will you please have a look and teach me what is wrong?

Created attachment 17712 [details] [review]
tentative patch, connecting key_press to the toplevel on focus-in

 There are two types of problems, I think. One is always 
conflicts, and other is not always conflicts.

 Example of "always" is, starting system line window
by typing F10.

 Example of "not always" is, converting hiragana strings
to roma-ji strings by typing F10 when we are inputting
preedit.

 To solve the former seems very very diffcult (or essencialy
impossible) and it seems no one have the idea.

 To solve the latter, there is a proposed patch, but I think
the patch has some problem.

 1. the patch is XIM specific, so it cannot be a solution for 
other immodules.

 2. connecting signal to toplevel will not work if the widget
exists in client side. (should I use plug instead of client?)

 Second problem is my guessing, so if I'm wrong, please
corect.

 To solve the second, we should discard the idea "steal", I 
think.

 I proposed new idea at gtk-list, and you can see that in 
this thread:
http://mail.gnome.org/archives/gtk-list/2003-September/msg00006.html

I made a proposal patch to add new function,
gtk_im_context_filter_pre_keypress.

This function is called in gtk_propagete_event, so input method can
recieve key event before widgets, menubar,and so on.

I know this patch is ugly a bit and wouldn't be solution for embedded
widget within a Plug/Socket combination. But for practical Janapese
input method (I guess also Chinese input method), this bug is quite
painful in some case. So, for the present, this patch have worth to
apply, I think.

But, this patch still have a big problem. In this proposal patch,
im_context is set to GtkWidget by g_object_set_data, so it wouldn't
work with original widget (ex. gtkmozembed). I hope someone has a
good idea.

Created attachment 23706 [details] [review]
proposal patch to add new functon filter_pre_keypress

Adding the PATCH keyword.

Any progress?

*** Bug 143824 has been marked as a duplicate of this bug. ***

Created attachment 80288 [details] [review]
Update for patch #23706

Do you have any updates?
I've updated the original patch for HEAD. It works fine with me.

Any progress after 10 years? In reality, as Hidetoshi point out, many working CJK input methods have some sort of "English mode" that leaves almost all special keys intact. Making input methods filter all keys first, with this "English mode", will make everyone happy; on the contrary, making application eat up special keys just leads to broken input methods (or hacks like key_snooper) and terrible user experience for many, many CJK users.

The big misunderstanding I saw here, is to think that the set of keys filtered by an input method is static. No, an input method can be very dynamic, stateful and can have such "English mode" bypassing most special keys to interact with applications as you want. The conflict is not really a conflict. In my opinion a working solution is that the GTK+ team demands such convention to be one of guidelines an input method should obey, and reserve only minimum number of keys (such as Ctrl + space) to change modes or to switch input methods. This is already a convention, so you are just regulating something that people already followed.

In summary, pleas let input method filter keys first, and you can demand such "English mode" to input special keys. The "English mode" is already there anyway. This might not be the best solution, but I think it's much better than the status quo.

(Is this suggestion concrete enough?)

> (Is this suggestion concrete enough?)

no

Hi Matthias,

Could you possibly elaborate so that we can make progress? My suggestions are the following:

(1) Allow IMs to interpret keyboard events first. There are already patches contributed by others, attached right within this thread. Perhaps they need some updates to fit into the current GTK+3 code base, but I guess this counts as "concrete".

(2) Reserve a few key combinations for input methods to toggle the "English mode". For example, we can pick Ctrl + space. I admit I didn't explicitly write down a list of key combinations, but we can look at, for example, the default toggling key combination list shipped by iBus. Please tell me if you are looking for that list. I believe we (including many amazing people watching this thread) can build consensus on a very small set of key combinations that should be reserved for input methods.

(3) Explicitly recommend all input method modules to provide such "English mode" with respect to the above reserved key combinations, if they want to intercept any special keys. I admit I haven't attach a diff patch for the documentation, but I guess we need to wait for (2).

I hope this looks more concrete now. Thanks.

As I describe on the gtk-devel-list recently, all popular input method framework are using and they must use gtk_key_snooper to make input method work right, this is a very long history ever since scim is maintained. With using this function, they have already crossed the line of gtk-im-context's interface, so why not move the line a bit forward?

This is already cause so many troubles in gtk application for years while other toolkits have already done it right for a long time, you can take a look at qt implementation.

(2)
Ctrl+Space is the most common one. there are some special key only used by very special keyboard layout. For Japanese and Hangul they use a special key only apper on theirs layout.

Some other key including "Ctrl+Shift" "Alt+Shift" (Yes, only combine key).

I think those should goes to HIG just like "Ctrl+C" and "Ctrl+V". 

(3)
No need to recommend actually, it's kinds of the "truth" or "rule" in input method world. :)

A Wayland input method proposal several years ago tried to make the input method transparent to applications. That is, applications cannot distinguish text inputs from a hardware keyboard directly, an input method, a virtual keyboard, or something unimaginable. I am looking forward to the day where the proposal is realized, and then we can just use Wayland and move on.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new