[immodule-qt] commit while preedit is being kept (Re: svn repository malfunction)

[Choe Hwanjin]

On Fri, Sep 10, 2004 at 02:19:26PM +1000, Leon Ho wrote:
> > Yes, this model inherits Trolltech's original XIM
> > implementation. At least Qt/Embedded's own input method facility
> > is also using same model.
> > 
> > >   But, some input methods may want to commit a string to the client
> > > before the end of composing (while displaying a preedit string).
> > 
> > Did you say that m17n-latin-post and m17n-vi-viqr are such IM?
> > 
> > Regardless of the answer, please let me know (other) such IMs as
> > examples. Actual implementations will indicate real requirements
> > to make proper decision.
> 
> As an example, I can think of korean input methods (nabi or hangul LE)
> are usually commit character when composing.
> 
> A test case would be 'rksk' keystrokes. Typing the whole 'rksk' will
> commit the 'rk' character, and the 'sk' will be still in preedit buffer.
> 
> I found out this when I was debugging a problem in gtkhtml. The cause of
> the problem is because the preedit buffer still contains characters
> after commit.
> 
> Leon

Your point is right.
Korean input method needs to commit when preedit string presents.
This problem make old input method ami not work well with Qt.
So, my new korean input methods use some trick.
When context needs to commit, it first clears preedit string, commits,
and then updates preedit string.
This is the same trick that Su Zhe pointed:
http://freedesktop.org/pipermail/immodule-qt/2004-September/000526.html

And many XIM clients and im module clients want no preedit string before
commiting. This makes korean input method implementation somewhat agly,
and flicker too much. 

> 
> 
> _______________________________________________
> immodule-qt mailing list
> immodule-qt at freedesktop.org
> http://freedesktop.org/mailman/listinfo/immodule-qt