Thanks for your time in review Sergey and Semyon.
-----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 7, 2018 8:11 AM To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com>; Semyon Sadetsky <semyon.sadet...@oracle.com> Cc: awt-dev@openjdk.java.net Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate() Looks fine. On 05/03/2018 21:32, Shashidhara Veerabhadraiah wrote: > Hi Sergey, I tested for the problem bug 6404832 and found that issue is not > happening anymore. Anyway this old bug was specific to Windows XP and there > was no problem with windows 2000, Windows 2003. But tested and found that > there is no issue as said in the bug. > > I have modified the test per your comments and here is the new Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.02/ > > Thanks and regards, > Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, March 6, 2018 12:04 AM > To: Shashidhara Veerabhadraiah > <shashidhara.veerabhadra...@oracle.com>; Semyon Sadetsky > <semyon.sadet...@oracle.com> > Cc: 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 confirm that the bug6404832 is not reproducible after this > change(since part of it fix is dropped)? > > Please use some meaningful name for the test + small typo in the > test(poistion) please fix both before the push. > > On 27/02/2018 00:45, Shashidhara Veerabhadraiah wrote: >> Hi Semyon, Thanks for your help. I did some debugging from that >> perspective and could find the problem and the solution. Here is the >> new webrev, please review it: >> >> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/ >> >> The problem was that in the case of SCROLLBARS_NEVER, scroll bar info >> was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0). >> This forced the windows to pick a default value and hence reset it to >> that value every time. Now the logic is modified in a very similar >> fashion as the other scroll bar display modes but without displaying >> it using the new win api ShowScrollBar(). The scroll bar info is >> supplied with a proper range per the corresponding base component but >> without the scroll bar pane size(as we don’t display it). This should >> suffice a good range for the scroll bars to operate and correct >> itself if there is any out of range value is supplied. >> >> Thanks and regards, >> Shashi >> >> *From:*Semyon Sadetsky >> *Sent:* Tuesday, February 27, 2018 1:22 AM >> *To:* shashidhara veerabhadraiah >> <shashidhara.veerabhadra...@oracle.com> >> *Cc:* awt-dev@openjdk.java.net >> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in >> ScrollPane is reset after calling validate() >> >> The bug was failed against Windows platform. So, I'd try to find the >> root cause why when the scroll is notified with the scrolled >> component size the scroll position is set to the wrong value. >> >> --Semyon >> >> On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote: >> >> 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 <mailto: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#S >> C >> ROLLBARS_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#S >> C >> ROLLBARS_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#S >> C >> ROLLBARS_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 >> >> >> 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 >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey.
