Re: XIM application frozen on gtk+1.3.*

[Owen Taylor <otaylor redhat com>]

tajima <hidetoshi tajima eng sun com> writes:

> >> >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.
> 
> Well, I have two reasons for wants of spot location. It is often the case
> that input methods use lookup choice windows to select a choice among
> candidates, and these windows are typically poped up near the insertion
> point, so that users can keep his eyes on the point.

Yeah, this is a bit of problem. Even internal to GtkIMContextXIM
we'll have to deal with this problem in some form when rendering
the status (though that doesn't need to be near the cursor as
much as choice windows do.)
  
> Another reason is that there are still many XIM modules which don't support
> on-the-spot. Fallback to Root-Window mode can be a workaround, but
> not all user will like it.

There are a few other reasons that make over-the-spot input
hard with GTK+-2.0 other than simply spot location:

 - Rendering style may not match at all since rendering isn't
   happening through Xlib's XOM code.

   (As an extreme case, imagine a vector illustration program
   that is wrapping text rendered with postscript outlines
   around a curve.) 

 - GTK+ has no good way to get a fontset to provide the input
   method.

I want to support non core protocol fonts even in GTK+-2.0.x,
(for x > 0) so the more we can have GTK+ draw, the better.

But basically, the main reason I don't want to support over
the spot drawing is that I don't want applications to have
to support it, or even know what it is. I think by keeping
the options small and the interface simple, we can encourage
developers to do things properly so that users get the
advantages of properly working input methods.

To take a rather GTK+-centric view of the world, if GTK+
does on-the-spot well, and doesn't do over-the-spot input,
I think the pressure will be on IM developers to support
on-the-spot, not GTK+ to support over-the-spot input.

(I've been told that Windows only supports on-the-spot
and RootWindow feedback.)
 
> >> 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.
> 
> Sure, let's get back to the original frozen problem, but I'd like to raise 
> over-the-spot as a separate problem, too.

Sure, and I'd say we may want to have some sort of support
for spot-location hints even if we don't support over-the-spot.

Regards,
                                        Owen