You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Alexey A. Ivanov (JIRA)" <ji...@apache.org> on 2006/11/24 12:21:02 UTC
[jira] Created: (HARMONY-2304) [classlib][swing]
j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
[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
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
[jira] Assigned: (HARMONY-2304) [classlib][swing]
j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2304?page=all ]
Nathan Beyer reassigned HARMONY-2304:
-------------------------------------
Assignee: Nathan Beyer
> [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
> Assigned To: Nathan Beyer
> 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
[jira] Updated: (HARMONY-2304) [classlib][swing]
j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2304?page=all ]
Alexey A. Ivanov updated HARMONY-2304:
--------------------------------------
Attachment: H2304-visual_position_tests.patch
This tests show the problem: most of them fail on Harmony. All of them successfully pass on RI.
> [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-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
[jira] Updated: (HARMONY-2304) [classlib][swing]
j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ 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
[jira] Assigned: (HARMONY-2304) [classlib][swing]
j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Beyer reassigned HARMONY-2304:
-------------------------------------
Assignee: (was: Nathan Beyer)
Unassigning, so someone else can pick up this issue.
> [classlib][swing] j.s.text.CompositeView.getNextVisualPositionFrom should use another algorithm
> -----------------------------------------------------------------------------------------------
>
> Key: HARMONY-2304
> URL: https://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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-2304) [classlib][swing]
j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2304?page=comments#action_12454535 ]
Nathan Beyer commented on HARMONY-2304:
---------------------------------------
I've applied the test patches and the patch to exclude the tests. Please verify this.
Is your intention now to submit a patch to correct the broken implementation? Will you do it on this issue? I don't want to resolve this issue, since the "bug" is not really fixed, just identified.
Thanks.
> [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
> Assigned To: Nathan Beyer
> 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
[jira] Commented: (HARMONY-2304) [classlib][swing]
j.s.text.CompositeView.getNextVisualPositionFrom should use another
algorithm
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2304?page=comments#action_12457288 ]
Alexey A. Ivanov commented on HARMONY-2304:
-------------------------------------------
Everything's fine with the patch applied.
You're right: the bug is not fixed, thus the issue should be left open.
I was going to correct it but I'll be unable to do it in the nearest future so anyone is free to fix it.
> [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
> Assigned To: Nathan Beyer
> 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