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.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()
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.veerabhadra...@oracle.com>
<mailto:shashidhara.veerabhadra...@oracle.com>
*Cc:* 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()
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#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
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
