Re: Another --> Re: GtkMovementStep of GtkTextView



Kaixo!

On Tue, May 22, 2001 at 08:42:34AM -0600, Mark Leisher wrote:
 
>     Pablo> No, not Vietnamese vowels (where do you get that idea about
>     Pablo> Vietnamese?
> 
> Testing with native users.  And also playing with a couple new Vietnamese word
> processors while I was in Hanoi last month.  As it was explained to me, it is
> very inconvenient to delete the whole vowel when you only want to change the
> tone mark (apparently a common "misspelling").

Mmh, while I think also that is a nice behaviour while editing; it is
the same while modifiying an already existing file?

> Yes, with Han input, using either Pinyin or Kana, the process used to
> choose a particular Hanzi/Kanji is often discarded,

For all input methods for all languages the process is discarded.
an 'udiaeresis' can be entered with one or two keystrokes (or even more
complicated ways, like typing a mnemonic like '&u:' or 'u00fc'; the yudit
editor allows it for example).

> The whole point of this discussion is about the expected editing
> behavior from users.  That is what Chinese and Japanese users have come to
> expect.  Other script users expect different things, even if the input process
> appears to be the same.

In fact it is the process of the existing text that I wonder if it isn't
the same, rather than the input method.

The handling of the BakcSpace could be simplified a lot if it acted
in a simple way on already existing text (just remove the previous conjunct
in a whole, like delete deletes the next one), and have the special
behaviour of BackSpace only removing portions of the conjunt when in the
specific input method (if it is handled by the input method it can be
complexified depending on the needs of the given language and/or input 
method).

Would that be an acceptable thing from users point of vue?
I think that it is, but want feedback from people using the more
concerned languages (indic languages), and also others.
However, I'm afraid that I haven't been very well understood on what my
idea was. So, I will try to explain it again, in a simpler way:

- when moving the cursor around in an existing text, have a common behaviour
  for BackSpace, a simple behaviour, delete the previous visual block.

- when editing (that is, typing letters and not cursor motion) have the
  backspace undo the last action, the last keystroke, and that will be
  handled by the currently used input method (which has information about
  the keyboard input flow that a text doesn't have)


(in the case of the indic i vowel, the one that goes before the letter,
the above difference is important, as when moving the cursor around it is
done in visual order, so placing the I-beam after a ka-i (which visually
looks as i-ka) will delete the ka; while on input after typing key 'ka' 
then key 'i' then BakcSpace, it will elete the 'i')

-- 
Ki a vos vye bn,
Pablo Saratxaga

http://www.srtxg.easynet.be/		PGP Key available, key ID: 0x8F0E4975




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