<AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

Shashidhara Veerabhadraiah shashidhara.veerabhadraiah at oracle.com
Thu Mar 1 04:09:44 UTC 2018


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).

 

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:

 

HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.01/"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 HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"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 <HYPERLINK "mailto:semyon.sadetsky at oracle.com"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 HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"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 HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"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

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"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

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"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 HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"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: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/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/20180228/943deeea/attachment-0001.html>


More information about the awt-dev mailing list