Re: XIM application frozen on gtk+1.3.*

[Owen Taylor <otaylor redhat com>]

tajima <hidetoshi tajima eng sun com> writes:

> >After some investigation, the problem here is that the XIM code
> >in GDK is interfering with the operation of the module - 
> >XFilterEvent is effectively being called twice which triggers
> >a loop.
> 
> I see. When kinput2 does not filter a key event while Japanese input
> is on and returns it to application, that event gets infinitely bounced
> between the gdk-X11 and GtkIMContextXIM, and gets in a loop.....
> 
> >So, the immediate workaround is to configure GTK+ with
> >--disable-xim. The slightly longer term solution is to remove
> >all the XIM code from GDK.
> 
> If we either disable or remove GDK's XIM, GTK+ applications and widgets
> have to trasfer to new IM Framework in order to get input method worked,
> correct? Hmm, how many gnome applications and widgets are there
> which directly uses gdk_im_* APIs? I know Mozilla does..

Its a very small set. Mozilla may be the only app that is handling
anything more than RootWindow mode.

I think changing the IM APIs is the price of progress. With the 
new input-method module stuff, we get:

 - Non-XIM based input methods like the compose methods shipped
   with GTK+. (Which will include features such as hex-entry of unicode)

   These are very simple to write, so people can easily write input
   methods for there own languages.

   Writing new input methods for XIM is very difficult.

 - A much simplified API, so people should be able to use the input
   methods more easily than they coudl with GdkIM

 - Ability to use new systems like IIIMF.

The old GdkIM stuff was a simple wrapper around XIM, and didn't
really fit in all that well with the way that GTK+ works. (It was
far better than not having IM support at all of course.)

> >It should be noted that the way that GtkIMContextXIM handles
> >interaction with Xlib is definitely not fully compliant with the way
> >XIM is supposed to, and while kinput2 seems to work reasonably well,
> >other input methods probably will need some changes to the 
> >way the module works.
> 
> Can we extend IM framework and allow XIM module to support
> Over-the-spot and Root-window inputstyle as well? Root-window style
> is relatively easy and Over-the-spot oughts to work *to some extent*
> if gtk window can set spot-location.

Root-window should work now. I'm not sure I want to add over-the-spot
handling. I think it complicates the interface more than it is worth.
 
> Then, most of existing input methods would work with the XIM in
> the new IM Framework, almost equivalently to the GDK's XIM.

Well, the problem I think we have now is not that input methods
require over-the-spot handling, but that input methods try to do some
stuff that doesn't work well with the way gtkimcontextxim handles
events.

Regards,
                                        Owen