<AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()
shashidhara.veerabhadraiah at oracle.com
shashidhara.veerabhadraiah at oracle.com
Thu Mar 1 18:09:06 UTC 2018
Thank you Semyon for the review.
On 01/03/18 11:16 PM, semyon.sadetsky at oracle.com wrote:
>
> On 3/1/18 9:37 AM, semyon.sadetsky at oracle.com wrote:
>
>> On 2/28/18 8:09 PM, Shashidhara Veerabhadraiah wrote:
>>
>>> Hi Semyon, It is not getting decreased for the case of
>>> SCROLLBARS_NEVER. The Boolean flags “needsHorz” and “needsVert” are
>>> false for the never case and true for the other cases. We decrease
>>> by the size of the scroll bars only for the true cases, so in the
>>> false case we will use the entire width and height(SM_CXEDGE and
>>> SM_CYEDGE).
>>>
>> Can you clarify this a bit more? I see the next lines executed
>> without any conditions
>>
>> 215 parentWidth -= (horzBorder * 2);
>> 216 parentHeight -= (vertBorder * 2);
> I was not right this is just borders.
>
> Looks good to me.
>
> --Semyon
>>
>> --Semyon
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>> *From:*Semyon Sadetsky
>>> *Sent:* Thursday, March 1, 2018 12:39 AM
>>> *To:* Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
>>> *Cc:* awt-dev at openjdk.java.net
>>> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>>> ScrollPane is reset after calling validate()
>>>
>>> Hi Sashi,
>>>
>>> The parent with and height shouldn't be decreased by the size of the
>>> scrollbars in case of SCROLLBARS_NEVER.
>>>
>>> --Semyon
>>>
>>> On 2/27/2018 12:45 AM, 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/
>>> <http://cr.openjdk.java.net/%7Esveerabhadra/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.veerabhadraiah at oracle.com>
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>
>>> *Cc:* awt-dev at openjdk.java.net <mailto:awt-dev at 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.sadetsky at oracle.com
>>> <mailto:semyon.sadetsky at 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.veerabhadraiah at oracle.com>
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>> <mailto:awt-dev at 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.veerabhadraiah at oracle.com>
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>> <mailto:awt-dev at 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.veerabhadraiah at oracle.com>
>>> <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>> <mailto:awt-dev at 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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180301/693ed3e4/attachment-0001.html>
More information about the awt-dev
mailing list