Re: GtkMovementStep of GtkTextView

[Chookij Vanatham <chookij thestork eng Sun COM>]

Hi Owen, Havoc, Robert, ....

GTK_MOVEMENT_VISUAL_POSITIONS will call "pango_layout_move_cursor_visually()"
by the number of "count" which is the number of "character".
I haven't seen it using "is_cursor_position" of PangoLogAttr.

gtk_text_layout_move_iter_visually(..., count, ...)
{
    ....
    ....
    while (count != 0)
      {
        ...
        pango_layout_move_cursor_visually();
        count++;
        ...
      }
}

I looked at pango_layout_move_cursor_visually() and it doesn't use
"is_cursor_position".

As a result of this, everytime, when I type "arrow-key", I-beam
is moving for the next character (visually). This is right for
"graphemes" movement, I guess if I really do understand the meaning
of "graphemes".

For Thai and for the case of application which has the cursor shape
like I-beam, everytime when the arrow-key is hit, I-beam cursor won't
be allowed in between conv and vowel. Another word, I-beam will be
moved based on "cluster". This should be different than "graphemes", I guess.

Here is the sample.

index:              0  1  2  3  4  5
Logical stream:    c1 v1 c2 v2 v3 v4

                   v1  v2 v3 v4
Visual display:    c1  c2           <--- 4 clusters

If I-beam is displayed in front of c1 and "arrow-key right" is hit,
for Thai, I-beam will be needed to placed in between v1 and c2 and
this means between index 1 and 2 (as logical). This movement is based
on cluster (not graphemes) for Thai.

As Havoc mentioned belowed ....

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

Please let me know if anything isn't well explained....


Chookij V.


] 
] Chookij Vanatham <chookij thestork eng Sun COM> writes:
] 
] > Hi Owen, Havoc,...
] > 
] > 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.
] 
] What would the difference between this and GTK_MOVEMENT_VISUAL_POSITIONS,
] which is meant to move by "graphemes" as determined by is_cursor_position
] of PangoLogAttr?
] 
] I believe these graphemes will be the same as you mean by "clusters"
] for Thai.
] 
] Regards,
]                                         Owen
] 
]