Re: Another --> Re: GtkMovementStep of GtkTextView



Hi Owen,....

] From: Owen Taylor <otaylor redhat com>
] Subject: Re: Another --> Re: GtkMovementStep of GtkTextView
] To: gtk-i18n-list gnome org
] 
] Vikram Subramanian <vikrams www chennailug org> writes:
] 
] > > Neither do Arabic people like the Backspace after "Lam-Alef" to delete
] > > both letters.
] > >
] > > --roozbeh
] > 
] > Hi,
] >     I posted this issue at the Tamil Linux group. The general opinion seem
] > to point toward undoing the effects of the last key pressed and not
] > deleting the entire cluster. Mostly people type the wrong vowel to combine
] > with the consonant and want to undo only the vowel part and not the base
] > consonant with it. Ofcourse it's always better when it's kept configurable.
] 
] This seems to be a general consensus for behavior during input for a lot
] of languages.
] 
] Doing this editing, doing this is relatively easy, since it can at the
] input method level.  The main disadvantage is that languages that
] otherwise don't require an input method (like Tamil) would then
] require an input method. But an input method can also provide the
] additional advantage of prohibiting the entry of invalid sequences,
] when the language has such.

I'd like to say the important thing and I don't really have input method
experience so, correct me if this isn't the case.

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.

For my opinion, all other indic scripts would like to have the same
behavior. The reason I say that, Thai is derived from the similar root
of languages as indic does. So, if input method that is being to be used in
indic scripts and require another keystroke to say "commit", I'm not sure if
that's really what indic wants.

Chinese/Japanese/Korean have the complex input. They have been developing
the ways to input their scripts which are acceptable and make sense (I guess)
for their scripts. Thai/Indic are not the complex input
(but they are complex output) and we get used to/accept just very very very
simple input by typing/keying one key stroke to input one character...

I'd like to point out that after Chinese/Japanese input method being
commited from users by typing the commit key or somehow selecting the
kanji/chinese characters they want from either kata/hira/pinyin/...,
those kanji/chinese characters will be seen as ONE character in the
text, that's why when users type <backspace>, users don't care whether
how many kata/hira/pinyin/... characters forming those kanji/chinese
chacters, and because kanji/chinese is considered as one character(glyph)
and that's why <backspace> will just delete that kanji/chinese character/glyph.
No need to worry about kana/hira/pinyi at that time.

So, another word, <backspace> at either chinese/japanese input method
or at the existing text, is just delete the key typed or the character
before the I-beam. This is same as Thai/Indic... 

This is what I though... :)


] 
] The other half of the question is whether it should be possible to delete
] the last character in a grapheme when editing existing text, or whether,
] in that case, delete should delete the entire cluster.

Actually, hopefully, as a lot of emails exchanged, we would be able to
come up with the consensue on this. This is really important....

Chookij V.

] 
] Regards,
]                                         Owen
] 
] _______________________________________________
] 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]