I think I agree Semyon. Thanks for your detailed explanation. So how do we approach on this? I see a different behaviour on other platforms. Shouldn’t we have a common behaviour across platforms? I agree with your analysis and hence should we change the behaviour on other platforms so that all of them will have the same behaviour?
Thanks and regards, Shashi > On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky <semyon.sadet...@oracle.com> > wrote: > > On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote: > >> Hi Semyon, Thanks for your review and these questions help us to reach the >> right requirements. >> >> Without this change, there is different behavior on windows compared to >> Mac/Linux platforms. Hence this change is required to make the behavior same >> across the platforms. Since the scroll pane control is not displayed for the >> SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the >> user can move to a different position? Since we used to update/recalculate >> the scroll pane geometry caused changes to move to a different position >> other than the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as >> unusable as the user is unable to control the scrolling movement because >> neither he can set one setScrollPosition() nor the control is displayed to >> explicitly set the movement. Hope this answers your question. > You need to think once again about two facts I brought in my previous message. > > 1. User still may scroll using mouse wheel even when scrollbars are not > visible. > > 2. Visibility of scrollbars doesn't affect the requirement to notify the > scroll about the scrolled component size changes. If the scrolled component > was 500x500 in size and its position in the 200x200 viewport was (300,300) > after the size of the component is changed to 300x300 it may not be shown at > the same position because the previously visible component area doesn't exist > anymore and the scroll should be moved to (100,100). This should work in the > same way regardless the selected scrlollbar visibility policy. > > --Semyon > >> >> Thanks and regards, >> Shashi >> <> >> From: Semyon Sadetsky >> Sent: Saturday, February 24, 2018 2:12 AM >> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com> >> <mailto:shashidhara.veerabhadra...@oracle.com>; awt-dev@openjdk.java.net >> <mailto:awt-dev@openjdk.java.net> >> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is >> reset after calling validate() >> >> On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote: >> >> Hi Semyon, Whenever the container is resized we used to update the scroll >> pane sizes/geometry regardless of the scroll bar display policies. This >> resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is >> displayed or needed an update. This additional update posed issues for the >> SCROLLBARS_NEVER case where we are not supposed to display the scroll pane >> per the java doc, then why update? >> >> Scroll pane geometry gets updated in 2 ways, one thro’ setScrollPosition() >> and childResized(). So I derived the conclusion based on the javadoc >> information that since we don’t display the scroll pane there is no need to >> update the scroll pane geometry based on the childResized() as it was >> altering the position already set by the setScrollPosition(). This behavior >> is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar >> display to SCROLLBARS_NEVER didn’t made any difference. >> The only difference of SCROLLBARS_NEVER from others I got from javadoc is >> that the scroll bar controls are hidden. So the scrolling itself happens in >> the same way as in the case of visible scroll bars but it can be only >> controlled by mouse wheel or programmatically. In my understanding this >> means that the notification about the scrolled component size changes should >> happen in the same way as for all other cases. I see no reason for the >> differentiation that your fix introduces. What will happen if to remove this >> notification for visible scroll bars modes? >> >> --Semyon >> >> >> Thanks and regards, >> Shashi >> >> From: Semyon Sadetsky >> Sent: Friday, February 23, 2018 10:17 PM >> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com> >> <mailto:shashidhara.veerabhadra...@oracle.com>; awt-dev@openjdk.java.net >> <mailto:awt-dev@openjdk.java.net> >> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is >> reset after calling validate() >> >> On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote: >> >> Hi Semyon, Thanks for your review comments. >> >> Here are those different scroll bar pane modes and their description: >> Modifier and Type >> Field >> Description >> static int >> SCROLLBARS_ALWAYS >> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS> >> >> Specifies that horizontal/vertical scrollbars should always be shown >> regardless of the respective sizes of the scrollpane and child. >> static int >> SCROLLBARS_AS_NEEDED >> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED> >> >> Specifies that horizontal/vertical scrollbar should be shown only when the >> size of the child exceeds the size of the scrollpane in the >> horizontal/vertical dimension. >> static int >> SCROLLBARS_NEVER >> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER> >> >> Specifies that horizontal/vertical scrollbars should never be shown >> regardless of the respective sizes of the scrollpane and child. >> >> This javadoc, you've copy-pasted here, doesn't explain why in your fix the >> notification about changed child size is disabled for SCROLLBARS_NEVER case. >> Thanks and regards, >> Shashi >> >> From: Semyon Sadetsky >> Sent: Thursday, February 22, 2018 11:58 PM >> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com> >> <mailto:shashidhara.veerabhadra...@oracle.com>; awt-dev@openjdk.java.net >> <mailto:awt-dev@openjdk.java.net> >> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is >> reset after calling validate() >> >> Hi Shashi, >> >> Can you clarify what is the principal difference between SCROLLBARS_NEVER >> and other scroll policies that requires to avoid updating the scroll >> geometry according to the inner component size? >> >> --Semyon >> >> On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote: >> Hi All, Please review a code fix for the below bug. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8195738 >> <https://bugs.openjdk.java.net/browse/JDK-8195738> >> >> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/ >> <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/> >> >> Problematic platform: Windows only. >> >> Summary: This bug occurs only on windows platform and whereas the behavior >> is different on Mac/Linux platforms. Now after this fix there is common >> behavior across the platforms. >> The main problem was with resetting the state of the scroll bars even though >> the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar >> display policy. This resetting should not occur as the scroll bar display >> policy makes the >> scroll bar panes invisible. Hence except the setScrollPosition() calls, we >> don’t need to resize/update the scroll bars state upon calling the scroll >> bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are >> not displayed. >> >> Thanks and regards, >> Shashi >> >> >> > >
