Re: Adding context to GtkIMContextIM

[Owen Taylor <otaylor redhat com>]

Theppitak Karoonboonyanan <thep links nectec or th> writes:

> >  * This interface is specialized for only handling context sensitivity,
> >    and not reconversion driven by the input method. XIM includes
> >    the ability for the input method to tell the application to
> >    delete the text.
> 
> However, the reconversion is useful for more sophisticated Thai XIM,
> where invalid sequences can be corrected, instead of just being rejected.
> (This is supported in most Windows Thai Editions.)

Can you describe how this works in detail? (From the user's point
of view.)
 
> But this is not currently implemented in XFree86, anyway. We can leave
> it for the future.
> 
> > The idea here is keep application support for this for an application
> > or widget very simple.
> > 
> >  * If the application doesn't support the ::retrieve_context
> >    signal, the input method can just do the best it can without
> >    the context.
> > 
> >  * The application doesn't have to worry about complex parameters
> >    to ::retrieve_context that might raise questions like "what
> >    is a word".
> 
> OK. And just in case it's really needed, we can still let the bridging
> code analyze the "word boundaries" in the retrieved text, right?
> (Actually, we don't need to do that.)

Yes.
 
> That's right (for XIM as passive input filter).
> 
> >  - Reconversion driven from the input method is an exotic capability,
> >    and don't need to worry about it for now.
> 
> OK. But please be forewarned that we may need it in the future, for an
> active XIM to achieve the same quality provided by Windows. :->
> 
> > If that's correct, then I think it makes sense to to add the simple
> > interface for GTK+-2.0. If something more complex is needed, then we need 
> > to wait to add context/reconversion.
> 
> Maybe, the reconversion can be added in the future as another signal,
> say, ::substitute_context? In that case, the bridge needs to decode
> the XIMStringConversionOperation before emitting ::retrieve_context or
> ::substitute_context signal accordingly.

Certainly adding a simple interface now and a more complex one
later could be done; if we are going to do that, however, I'd
like to have some vague idea of what the more complex interface
would look like so that we can make sure that the pieces fit
together.

Regards,
                                        Owen