Re: Adding context to GtkIMContextIM

[Theppitak Karoonboonyanan <thep links nectec or th>]

On Tue, Oct 23, 2001 at 04:12:14PM -0400, Owen Taylor wrote:

>  * A GtkIMContext::retrieve_context signal that asks the context
>    to set as much context as is available around the insertion point 
>    up to an entire paragraph.

This should be fine.

(In fact, it just requires up to a previous non-combining character in the
context for a sophisticated Thai XIM, and just a previous character for
an average Thai XIM, provided that the cursor never falls upon a combining
character.)

>  * A method:
>   
>    void gtk_im_context_set_context (GtkIMContext *im,
>                                     const gchar  *text,
>                                     gint          len,
>                                     gint          insert_index);
> 
>    That a client calls in response to the ::retrieve_context signal.
> 
>   A method:
> 
>    gboolean gtk_im_context_get_context (GtkIMContext *im,
>                                         const gchar **text,
>                                         gint         *insert_index);
> 
>   That clears the current context set on the IMContext, emits ::retrieve_context, 
>   and if new context has been set with set_context(), returns that.

This is fine (for non-reconverting retrieval).

> Compared to the XIM interfaces, there are are two main simplifications
> here.
> 
>  * There is no fine grained control over what text is returned other
>    just "get the surrounding paragraph". This isn't isn't a problem
>    for context sensitive input methods. If they want less text, they
>    can simply use less text. There is a problem for bridging to XIM:
>    if the input method calls the StringConversionCallback with a 'direction' 
>    of, say, XIMCaretUp, then we can't handle that properly, since we don't 
>    have information about the layout of the context on the screen.

This is sufficient for Thai XIM, anyway.

>  * 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.)

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.)

> In a quick look it appears to me that IIIMF has no support for context
> or for reconversion. A similarly quick look at the Win32 IME API's
> indicated that Windows only supports reconversion driven from the
> application. In both cases, I could have easily have missed the part
> of the API for handling this.

This is weird, because Thai input method is very complete in Windows
environment. I don't know much about IME, though.

> Currently, I believe:
> 
>  - A simple interface as above should be enough for "context sensitivity"
>    as needed by Thai.

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.

Regards,
-Thep.
-- 
Theppitak Karoonboonyanan
Information Research and Development Division, NECTEC
http://www.links.nectec.or.th/~thep/  mailto:theppitak nectec or th