Re: Thoughts and questions about input

["Adam Sleight" <adams linearcorp com>]

> There are various styles of handling preedit strings:
> 
>  1) On-the-spot: the preedit string is displayed at the eventual 
>                  insertion location
>  2) Over-the-spot: the preedit string is displayed in a separate
>                    subwindow over the insertion location. (This 
>                    is typically done in such a way to provide
>                    a simulation of 1)
>  3) Off-the-spot: the preedit string is displayed in a separate
>                   area of the toplevel window. 
>  4) Root-window: the preedit string string is displayed in 
>                  a separate window.
> 
> GTK+ currently supports 2) and 4). For 1.4, I want to move this
> to supporting 1) and 4), since 2) does not look good unless you
> are sticking very close to the way Xlib renders things.

yes...definitely #1 is probably the most desirable...that's what I was trying to
elude to.

> > 
> > You can have tons of combinations...say for example someone choose Japanese
> > input method.  You can could input with a Japanese layout keyboard but I
> doubt
> > many people do it that way anymore.  Instead they just input romaji
> > (a,i,u,e,o,ka,ki,ku,ka,ko) rather than just "ka" as a single key.  Perhaps
> > allowing them to set a default as to when they change into a language of
> input
> > as to which keyboard layout would be nice.
> 
> I see this as mostly a matter of configuration of the input method.
> Once an input method is in use, it is up to it whether it looks for roman
> keysymbols or hiragana keysymbols.

> 
> The somewhat confusing thing when trying to accomodate both languages
> like Japanese and languages like Russian, is that, while for Russian
> you are either in "English" mode, or "Russian" mode, for Japanese, the
> choice is a bit different - you are either inputting through the input
> method or not inputting through the input method. So while a Russian
> user wants a hotkey to switch their keyboard between English and
> Russian, the Japanese user's hotkey keeps them set for Japanese, but
> activates and deactivates the input method.
> 
Well there is such a thing as English Mode while in Japanese Input Mode.  For
example if your typing vertically starting top to bottom and right side to left
side then you need to be in Japanese English mode.  Due to the fact that English
can't type vertically.  You'll see this all the time...especially in Japanese
computer magazines.

So for a few complicated languages I'm sure there will have to be multiple
hotkeys to switch to various modes within the language input mode.

> > > >  - via system setting. (This could be in a control-panel, or in
> > > >    a shortcut applet of some sort.)

> 
> This will certainly work with Pango. I already have samples running
> locally of GTK+ programs with some labels mixing, say, Korean and
> French. The same will work for entries and text widgets soon. Of course,
> applications will need some modification to load and save multi-lingual
> text correctly, but I don't think this will be that much of a burden.
> (Using Unicode makes this a lot simpler than it would be if we were,
> say, trying to do the same thing with iso-2022.) 

Not sure about the politics...but initially probably should be rolled out in
Unicode since it's the most "universal" solution.  However, in the future, would
it possible to support a few native encoding formats.

I read in CJVK by Ken Lunde p. 128 how the Unicode has 20,902 partially unified
Chinese characters. Perhaps eventually will GTK+ be able to support 121,000
Chinese characters?  Maybe 3 to 4 years from now.  Is the unicode based on 2.1
and later right?