One more thing, ScrollPane is also missing an often seen use case:
Transparent scrollbars, or scrollbars that fade out after use. For one
of my own panes, I've tweaked ScrollPane to have transparent scroll bars
which overlaps the content always (ie. the content is visible below the
scroll bar). I do this with a new ScrollBarSkin that just puts the bar
at a negative offset so it overlaps the content. IntelliJ does this for
example, as well as Visual Studio Code (for horizontal bar at least).
I think it already do this for touch platforms (embedded), but doesn't
offer it for other platforms. Someone filed a ticket for this:
https://bugs.openjdk.org/browse/JDK-8091365
--John
On 01/05/2023 23:21, John Hendrikx wrote:
I think we need to be very careful in adjusting preferred size based
on scrollbar visibility.
ScrollPane's are used to avoid putting pressure on the surrounding
layout. It's preferred size will often be ignored in most layouts
because its preferred size is the size of its content, which is likely
too large too fit (otherwise why use a ScrollPane). When a
ScrollPane's bounds become smaller, it must be careful not to change
its minimum space requirements, as that would be counter to its purpose.
However, even changing its preferred size when space is getting
tighter may affect layouts in a way you really want to avoid.
BorderPane is one of many layouts, and even though what we're seeing
may seem like a bug, changing this behavior may have consequences.
What if the ScrollPane is in a VBox with two elements set to
Priority.ALWAYS, one being the ScrollPane? When space gets tighter,
changing the preferred size to allow for a scroll bar is going to make
the layout jump a bit, because it will take away a bit of extra space
from the other element with Priority.ALWAYS. VBox uses the preferred
sizes of all children as a starting point, and shrinks them to be
smaller to fit -- changing the starting point (the preferred size)
suddenly to make room for a scroll bar is not going to be smooth.
I suspect in a lot of layouts the values for viewport width/height
will be set, as using the content as its preferred size for a
ScrollPane seems like a bad choice to begin with. In the VBox
example, the preferred size would be so large when there is a lot of
content that it would swallow most of the extra space from any other
nodes set to Priority.ALWAYS. Two ScrollPane's above each other would
not be equal sized, as their preferred starting sizes would be based
on their contents... it would look weird without setting viewport size
hints.
I could imagine that there could be a different scroll bar policy, one
where room is always reserved for scrollbars, but they still display
only when needed. This way, the ScrollPane, if it can be displayed at
its preferred size, would have sufficient room for a horizontal
scrollbar, and when it's horizontal size gets squished, it can display
it without needing to adjust its minimum or preferred sizes. If there
isn't enough room, it would pretty much function as before, where the
scrollbar overlays content when it does need to be displayed -- that's
unavoidable.
There's also a similar issue: https://bugs.openjdk.org/browse/JDK-8095135
--John
On 01/05/2023 22:18, Andy Goryachev wrote:
I think your diagnosis is right though: sometimes the layout is not
triggered when a property is changed,
the recent bug like that is
JDK-8307117 <https://bugs.openjdk.org/browse/JDK-8307117> TextArea:
wrapText property ignored when changing font
I wonder if some kind of a generic unit test could be developed to
identify such cases.
-andy
*From: *Nir Lisker <nlis...@gmail.com>
*Date: *Monday, May 1, 2023 at 13:09
*To: *Andy Goryachev <andy.goryac...@oracle.com>
*Cc: *openjfx-dev <openjfx-dev@openjdk.org>
*Subject: *[External] : Re: JDK-8199934: ScrollPaneSkin incorrectly
lays out its scrollbars
If I knew what the fix was I would have. Right now I'm not sure
anymore what the correct behavior should be even.
On Mon, May 1, 2023 at 10:44 PM Andy Goryachev
<andy.goryac...@oracle.com> wrote:
Nir, would you like to submit a pull request?
Thank you
-andy
*From: *openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of
Nir Lisker <nlis...@gmail.com>
*Date: *Sunday, April 30, 2023 at 10:04
*To: *openjfx-dev <openjfx-dev@openjdk.org>
*Subject: *JDK-8199934: ScrollPaneSkin incorrectly lays out its
scrollbars
Hi,
I took a quick jab at this issue [1]. Using the reproducer in the
ticket, launch and resize the stage vertically so that the
buttons at the bottom are only partially visible.
The current behavior is as follows:
When the scrollbar is not needed, toggling to the AS_NEEDED
policy reallocates the scrollbar space for the buttons (they move
up).
When the scrollbar is needed, toggling to the AS_NEEDED policy
still reallocates space, and the scrollbar takes away space from
the content node. This is wrong.
I modified the method 'computeHsbSizeHint' to
private double computeHsbSizeHint(ScrollPane sp) {
return determineHorizontalSBVisible() ?
hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0;
}
Now the policy toggling behavior is correct both when the
scrollbar is needed and when it's not - the space is reallocated
not at the expense of the content. However, enlarging the stage
horizontally while AS_NEEDED is selected does not reallocate the
space (you need to toggle the policies). I'm guessing there's a
missing call to layoutChildren during this resizing.
Does anyone have any input here?
Thanks,
Nir
[1] https://bugs.openjdk.org/browse/JDK-8199934
