Re: Another --> Re: GtkMovementStep of GtkTextView



Hi,

Thanks for clearifying this for me.
Then, it's great that, for Thai/indic, after typing key sequences and typing
<backspac>, it can delete just the last key typed.

So, as Owen mentioned, we need to figure out another half of question
which is the case of the existing text .... ?

Chookij V.

] Date: Sat, 26 May 2001 01:56:35 +0800
] From: Steve Underwood <steveu coppice org>
] Subject: Re: Another --> Re: GtkMovementStep of GtkTextView
] To: gtk-i18n-list gnome 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
] 
] _______________________________________________
] gtk-i18n-list mailing list
] gtk-i18n-list gnome org
] http://mail.gnome.org/mailman/listinfo/gtk-i18n-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]