Re: Another --> Re: GtkMovementStep of GtkTextView

[Steve Underwood <steveu coppice org>]

Chookij Vanatham wrote:
> [...] 
> For Thai, no matter Thai is requiring input method or not (now, it's not),
> as long as, everytime, when Thai character typed/keyed, we (Thai people)
> will not want to type another key (usually enter key) to say "commit"
> (like in japanese/chinese). Also, we don't want another input pop-up window
> for this input method. As long as the Thai character keyed/typed,
> it will be submitted to the logical steam (text), right away and the
> output method will take care it.

If I am reading your intention correctly, you are assuming "input
method" inplies "commit keystroke". This is not the case. Many East
Asian input methods are designed to allow the continuous free flow entry
of Chinese and Japanese. In fact, one of the interesting areas of R&D is
to reduce dependancy on on a commit operation. Most handwriting input
systems have no commit step, unless what you write is ambiguous - you
just write. Some phonetic input schemes are designed for continuous
entry. Commit is an alien concept for languages written in a continuous
unbroken form, like Chinese. On the other hand, English has a very
definite commit-like step - a great big space bar used at the end of
every word.

If you look at the XIM spec., it was intended to cover all langauge
needs - not just the needs of East Asian languages. XIM sucks in many
ways, but that doesn't mean the basic idea of a generic input framework
is bad. Everyone needs an "input method" when they move to things like
handwriting entry. GTK+ is being groomed for embedded use (frame buffer
mode), and it needs to deal as well with the Palm type environment as it
does the desktop.

Regards,
Steve