This is a very interesting idea. iOS does something similar, but I always thought than discoverability should be a priority. Perhaps if it would not fade to a complete transparency, but remained slightly visible. Or it might depend on a (global) option.
One thing you are right - it would require a different skin (skins, for all the components that use ScrollBars). -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx <john.hendr...@gmail.com> Date: Monday, May 1, 2023 at 14:43 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars 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><mailto:nlis...@gmail.com> Date: Monday, May 1, 2023 at 13:09 To: Andy Goryachev <andy.goryac...@oracle.com><mailto:andy.goryac...@oracle.com> Cc: openjfx-dev <openjfx-dev@openjdk.org><mailto: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<mailto: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<mailto:openjfx-dev-r...@openjdk.org>> on behalf of Nir Lisker <nlis...@gmail.com<mailto:nlis...@gmail.com>> Date: Sunday, April 30, 2023 at 10:04 To: openjfx-dev <openjfx-dev@openjdk.org<mailto: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
