Re: Thoughts and questions about input

[Pablo Saratxaga <pablo mandrakesoft com>]

Kaixo!

>>>> There are a few twists on these types. For instance, Thai is basically
>>>> just a separate keyboard layout, but there are prohibited combinations,
>>>> so there is a need for a simple input method to validate the input.

In fact is not the keyboard combinaisons that are prohibited, but the
codes combinaison on the stream of produced text.
A good thai keyboard support will involve not only a keyboard sending the
right codes (that is already done in XFree86); but also a way to accept
different combinaisons and canonize them.

Thai (and I thing it will be the case with all languages that use combined
codes (eg like writting an Acircumflex with two codes: A and ^, would it be
A^ or ^A ? Well, for the Acircumflex it is well established that the 
diacritic is typed first; but with some languages that is not so well 
established; so both inputs should be allowed; but a unique combinaison put
into the text stream).

That is also the case in vietnamese "telex style" input. A very popular
input method as it allows very fast typing. The vowels with a circumflex,
as well as the Dstroke, are written by redoubling the letter.
Then, unused letters of the latin alphabet (j,x,...) are used to indicate
the different accents. But those letters can be typed almost anywhere
on the syllabe (vietnamese is written with syllabes separated by spaces).
For example "Vietnam" in vietnamese is written with the "e" having a
circumflex accent and a dot below the letter.
With the telex input method: "Vieejt Nam" but also must be accepted
"Vieetj Nam" (yes, the accent is always on the last vowel of a syllab with
several vowels).
So, the keyboard input method must accept all those possibilities; but
produce a unique string of 8 letters: 
V - i - ecircumflexwithdotbelow - t - <space> - N - a - m

As you can see the needs in input can have similarities at times, and also
differences at another times; it is a very important point to tought at
when designing the API, so it can be used in all cases; if not it won't
be that useful.

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

Yes.
All the japanese input methods I know handle that by themselves.

>> I light this option best.  In the control-panel they can choose which languages
>> that they wish to have available for switching and in the right-click icon at
>> the bottom they can choose amongst those 2 or 3 or however many they prefer.
> 
> Yes, this is basically what I would imagine. (Though hotkey switching
> is clearly necessary too.)

Using the mouse is not practical (you have to leave the keyboard).
It would be better to have the small icon allowing to choose between *all*
the input methods and keyboards available; but accessing to a list of choosen
"fast access" ones (choosen trough control-panel) with a hot key combinaison.
Made that hotkey cyclic (most people will use only two: it will be exactly
as it is now for them), with a little visual output showing the current one.
 
> 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.

You can also imagine an input method (but direct, no need for a pre-select
window) for russian. For example my keyboard (a belgian one) only has latin
letters printed in it; switching to a russian keyboard will be very hard
for me, as I won't know what key to press for what.
I would much prefer to switch to a given ascii->cyrillic transliteration;
and be able to type: Do svidan'ja and have the proper cyrillic letters
appear. It is similar to the "telex" input of vietnamese I talked above:
the keyboard layout is not modified, only intepretation of letters is.
That kind of input methods is very important for inputing in some script
at time to time, but not regularly enough that you blindly know a keyboard
layout that has no relationship with was is printed on your keys.
 
>>>>  - Should the keyboard state ever change by something other than
>>>>    a user action? (From what I've seen of Macintosh docs, if you
>>>>    are using Arabic, then clicking in a segment of Arabic or 
>>>>    English will switch the keyboard state to match the new segment.)

I don't think it is a good idea. It seems a good thing at first sight, but
it will perturbate a lot people as it isn't very intuitive behaviour;
and will be the undesired behaviour on almost 50% of the cases (in a bilingual
text environment, how can the system decide which script you want to input
in at a given moment ?)

However, the application can want to switch the mode for some input boxes;
like a dialer phone number input for example; where the numbers must be in
ascii numbers, and not in halfwidth CJK ones, or in arabic shapes.
Or for the login, password, URLs, email, etc. fields. In other words, input
fields where the script used can be only one and we know it.

> Regards,
>                                               Owen
> -- 
> To unsubscribe: mail gtk-i18n-list-request@redhat.com with "unsubscribe"
> as the Subject.

-- 
Ki ça vos våye bén,
Pablo Saratxaga

http://www.ping.be/~pin19314/		PGP Key available, key ID: 0x8F0E4975