<AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()
semyon.sadetsky at oracle.com
semyon.sadetsky at oracle.com
Thu Mar 1 17:37:58 UTC 2018
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);
--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/747b247b/attachment-0001.html>
More information about the awt-dev
mailing list