WIP: Support scrolling (Overflow::Scroll) in bevy_ui

[nicoburns]

Objective

Allow users to create scrollable regions using bevy_ui.
Fixes #8074

Prior Art

https://github.com/Piefayth/bevy_ui_scroll

Solution

This is adapted from the scrolling implementation in the examples/ui/ui.rs example, but is improved in that it does not use the style system in order to apply offsets (which requires a relayout each time the scroll position changes, and interferes with users wanting to use that same style):

• A new Overflow::Scroll variant has been added to the Overflow enum to mark nodes that should be scrollable
• A system has been added that responds to mousewheel events and updates the scroll position
• Nodes are laid out like usual (layout using Taffy is not affected)
• The position of nodes is offset by the scroll position of their parent after layout while performing transform change detection

Requirements from Taffy:

• Support Overflow::Hidden DioxusLabs/taffy#424 (Correctly lay out Overflow::Scroll/Overflow::Hidden nodes)
• Support Overflow::Scroll DioxusLabs/taffy#446 (Support reserving space for scrollbars for Overflow::Scroll nodes)
• Output "scroll width/height" for each node DioxusLabs/taffy#470
• Track which nodes' scroll heights have changed in a given layout computation (for efficiently updating scroll_height in bevy on relayout only when actually necessary)
• Release new version

Tasks

• Add Overflow::Scroll variant to Overflow enum
• Add ScrollPosition component
• Add update_scroll_position system
• Only scroll the item under the cursor
• Horizontal scrolling
• Separate Overflow in each axis (Split UI Overflow by axis #8095)
• Update scrolling on relayout (height of node or contents may have changed)
• Make ScrollPosition component optional for ui nodes to avoid checking every node on scroll
• AccessKit (need to export scroll_x/scroll_y and scroll_x_max/scroll_y_max to accessibility tree)
• Touch-based scrolling for mobile platforms
• Nested scrollviews

---

Changelog

• Add support for Overflow::Scroll

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[nicoburns]

Hmm... This adds new variants to an enum and a new component to a bundle. Would bevy consider that a breaking change?

[viridia]

@nicoburns Question I have is, how will games control the appearance of the scrollbars? On the web, the ability to customize the look of scrollbars is quite limited (more so in some browsers than others), and the web community has generally punted on this issue by converging on a fairly common (and boring) visual design for scrollbars which nearly every UI toolkit adheres to. However, games want novel and fancy UI designs, and I think scrollbars are no exception. Granted, not many game HUDs have scrollbars, but there are exceptions:

• Chat logs in multiplayer games
• Quest and Lore pages
• Character bios in RPGs
• Help pages
• etc.

Editors and other tools built on Bevy UI are of course going to have lots of scrollbars, but their need for visual novelty is not quite as acute.

A related question is the API for controlling scroll position. "Scroll selected item into view" is probably the most common of these. If scrolling is just mucking around with the node transform, then user code which explicitly sets the translation is probably going to mess things up. We really ought to define an API to let user code do the standard things (scroll to top, scroll to bottom, show selected, etc.) without having to directly touch the node transforms.

As someone in the process of writing a UI framework, I'm perfectly prepared to do my own "scrollview" widget implementation if that's what it takes. I know that on the web, scrolling is a style property that is inherent in every element, but that is not the case in desktop toolkits such as Java Swing or Qt, where scrolling is a specific widget type. I actually think that model may be more appropriate, given the general rarity of scrolling views in games, but the question then becomes where do we draw the line between the responsibilities of bevy_ui and the responsibilities of the toolkit?

[zmarlon]

Is there anything new to announce?