harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey A. Ivanov (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-2304) [classlib][swing] j.s.text.CompositeView.getNextVisualPositionFrom should use another algorithm
Date Fri, 24 Nov 2006 11:40:03 GMT
     [ http://issues.apache.org/jira/browse/HARMONY-2304?page=all ]

Alexey A. Ivanov updated HARMONY-2304:
--------------------------------------

    Attachment: H2304-test-exclusion.patch

The patch to exclude these new test cases from test run.

> [classlib][swing] j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
> -----------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-2304
>                 URL: http://issues.apache.org/jira/browse/HARMONY-2304
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Alexey A. Ivanov
>         Attachments: H2304-test-exclusion.patch, H2304-visual_position_tests.patch
>
>
> In javax.swing.text.CompositeView, getNextVisualPositionFrom is divided into two methods:
getNextEastWestVisualPositionFrom() and getNextNorthSouthVisualPositionFrom(), i.e. horizontal
and vertical correspondingly. The implementation of both is to call Utilities.getNextVisualPositionFrom()
at the moment.
> The method in Utilities calculates the position and returns it. During the calculation
Utilities traverses the Element hierarchy in the document rather than the View hierarchy,
which is wrong. The View hierarchy should be traversed, and getNextVisualPositionFrom should
be called on several views while calculating. For example, this approach works incorrectly
if some views are not visible, like in HTML.
> My vision here is as follows. When getNextVisualPositionFrom() is called on a container
(i.e. CompositeView), the container should find child view
> representing the offset from where to find the next visual position. And then the container
calls getNextVisualPositionFrom() on the child it found on the
> previous step. If the method returns -1, the container has to provide alternative solution,
i.e. move to the next child or something like that. Also it should provide an algorithm for
the case where a child view representing the given offset is not found.
> Additionaly, when moving to another child, the container should use flipEastAndWestAtEnds()
to select the direction in which children were laid out (i.e. next child is at +1 index or
-1 index from the current one).
> The implementation of View.getNextVisualPositionFrom() should be revised as well. (Currently
it also forwards to Utilities.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message