Another --> Re: GtkMovementStep of GtkTextView

[Chookij Vanatham <chookij thestork eng Sun COM>]

Hi Havoc, ....

] Date: Sun, 13 May 2001 20:07:03 -0400
] From: Havoc Pennington <hp redhat com>
] Subject: Re: GtkMovementStep of GtkTextView
] To: Chookij Vanatham <Chookij Vanatham Eng Sun COM>
] Cc: otaylor redhat com, robert susu org uk
] MIME-version: 1.0
] User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
] 
] 
] Chookij Vanatham <chookij thestork eng Sun COM> writes: 
] > I'm trying to figure out how to move I-beam in GtkTextView by basing on
] > "cluster" of script.
] > 
] > After I debug/try to understand how the I-beam movement works,
] > I'd like to suggest to add 1 more type called
] > "GTK_MOVEMENT_VISUAL_CLUSTER_POSITIONS". This movement step will tell
] > GtkTextView to move I-beam based on script cluster information.
] 
] I don't think this is right - my understanding is that cursors should
] be at "grapheme boundaries" not cluster boundaries, the two are subtly
] different... GTK_MOVEMENT_LOGICAL_POSITIONS should have this behavior.
] 
I'd like to point out that, it's just only the position of I-beam is subtly
different,at least for Thai. Unfortunately, since the computer has been used
in Thai market, users will hit that key only 1 time to move to next cluster.
I don't think that we can force Thai users to the new behavior (graphems)
for the applications which has the cursor look liked "I-beam" even at least,
I-beam is moving a little little litte bit and it's hard to see if I-beam
is in between clusters or within cluster.

Let's say if the cursor look is not I-beam, let's say if it looks like
"blinking black box", like in Terminal, this case the cursor is drawn
on top or over the character. So, everytime hitting arrow-key and the cursor
is moved based on "graphemes" (in vi), to me as Thai users, I feel that
it's better than moving based on cluster because I can see the cursor
exactly drawn on idividual Thai character (either consonance, vowel, tonemark,
...)

I think that "GTK_MOVEMENT_LOGICAL_POSITIONS" is moving based on "grapheme"
and not "cluster". So, it shouldn't be used for this case, either.


] The Pango API at the moment just exposes
] PangoLogAttr::is_cursor_position and uses the Unicode grapheme
] boundary calculation to derive that.

I haven't seen this piece of code involving for the action of
"GTK_MOVEMENT_VISUALLY_POSITIONS" yet. May be, I might miss something.


] 
] > For sure, in Thai, I-beam will be moving based on cluster.
] > I guess that all other indic scripts would behave the same.
] 
] Doesn't this just mean that clusters == graphemes for Thai?

In Thai, for the cursor which has the look as I-beam, clusters will not
equal to graphemes.

In Thai, for the cursor which has the look as "blinking black box" which
is drawn over idividual character, I wouldn't say that clusters == graphemes.
Here is my though.

For the cursor movement and cursor is "black box", clusters == graphemes.
For the selection by mouse and the selected area is drawn as black area
and this is in terminal (gnome terminal), clusters will stil not be
equal to graphemes. Right ?


] 
] I think the right fix is to make pango_break() return the proper
] values for PangoLogAttr::is_cursor_position.
I'll take a look how pango_break() is invovled for cursor movement
algorithm.

] 
] Anyhow, if you do want clusters not graphemes, if we add
] GTK_MOVEMENT_VISUAL_CLUSTER_POSITIONS, I don't think it helps because
] there won't be a way to change whether keybindings do clusters or
] graphemes on a per-language basis. That is, we have to have for
] example the GDK_Right key do the same movement step for all
] languages.

That's correct. We problably need something that can be configured
to select either one of these behaviors...

Thanks for discussion and let's make sure that we can have this done
before APIs code-freeze....

Thanks again,

Chookij V.



] 
] Havoc