Bug 4819 - StyledText - bidi - cursor navigation (1GJLKSN)
Summary: StyledText - bidi - cursor navigation (1GJLKSN)
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: Lynne Kues CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 4716 4792 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-10-11 14:23 EDT by Lynne Kues CLA
Modified: 2001-12-10 11:54 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lynne Kues CLA 2001-10-11 14:23:32 EDT
*** Cursor up and cursor down should move visually not logically.

*** Page up and page down should maintain the x position of the cursor visually (not logically).

*** Next/previous word should be logical.  In the following scenario word next does not work correctly:

         LLL RRR RRR RRR LLL

    If you start at the visual beginning of the line and press Ctrl-Next Arrow, the second ctrl-nextArrow
    should place the cursor at the logical beginning of the next word, which would be at the end of the
    last "RRR" visually.

NOTES:

LK (06/09/2001 11:08:53)
	We are like other editors with respect to our behavior, but this is not the most desired
	behavior.

MA (06/09/2001 17:51:26) LK's note above about "being like other editors" applies only to the Ctrl-nextArrow
	item.  As for Cursor-Up, Cursor-Down, PageUp, PageDown, most Windows applications 
	(including Notepad) behave visually as in the Bidi requirement.

MA (06/09/2001 14:44:49)  Severity: medium

KH (9/7/2001 10:08:22 AM)
	We have similiar problems in English. 

KH (9/7/2001 10:08:38 AM)
	Priority 3. 

LK (10/09/2001 12:00:39)
	PageDesigner does support visual cursor navigation on cursor up and cursor down.  It follows
	logical navigation on curor next/prev.  With respect to next/prev word, we act like PageDesigner.

KR (05/10/01 17:13:12)
	Next/previous word works like cursor navigation at direction boundaries. That's why
	word-next, word-next in the scenario above places the cursor logically behind (visually in front of)
	the visually last RRR. The first word-next places the cursor logical at the beginning of the visually 
	last word. It just happens to be visually behind the first LLL because that's how cursor navigation 
	works. We may be able to change this easily by setting the lastCursorDirection to PREVIOUS as if
	we moved from L2R in the RRR segment. That way the cursor would be visually on the right side (at 
	the beginning) of the RRR segment.

KR (05/10/01 17:52:09)
	Fixed the line up/down and page up/down cursor movement. It now works visually so that
	the cursor stays close to the same horizontal position. 
	Leaving PR open to look into the word movement.
Comment 1 Knut Radloff CLA 2001-10-15 13:25:39 EDT
*** Bug 4716 has been marked as a duplicate of this bug. ***
Comment 2 Knut Radloff CLA 2001-10-15 17:39:34 EDT
Not changing the word movement. The movement suggested in the Bidi Guidelines 
by MA is visual. In the example above word next starting at the beginning of 
the line would move to the visual right side of the *first* R2L word.
This behavior would be entirely different from the logical approach taken in 
almost all other StyledText (and PageDesigner) functions and non-trivial to 
implement.
Leaving word movement logical since most other editors work the same way.
Comment 3 DJ Houghton CLA 2001-10-29 16:41:00 EST
PRODUCT VERSION:
134

Comment 4 Knut Radloff CLA 2001-11-06 17:21:07 EST
*** Bug 4792 has been marked as a duplicate of this bug. ***