-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Support scrolling (Overflow::Scroll
) in bevy_ui
#8104
Conversation
29aa3a0
to
4379fd5
Compare
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? |
Hmm... This adds new variants to an enum and a new component to a bundle. Would bevy consider that a breaking change? |
dddd297
to
8a33a96
Compare
63d9c8f
to
cf4bfb6
Compare
@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:
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? |
# Objective - Enables support for `Display::Block` - Enables support for `Overflow::Hidden` - Allows for cleaner integration with text, image and other content layout. - Unblocks #8104 - Unlocks the possibility of Bevy creating a custom layout tree over which Taffy operates. - Enables #8808 / #10193 to remove a Mutex around the font system. ## Todo - [x] ~Fix rendering of text/images to account for padding/border on nodes (should size/position to content box rather than border box)~ In order get this into a mergeable state this PR instead zeroes out padding/border when syncing leaf node styles into Taffy to preserve the existing behaviour. #6879 can be fixed in a followup PR. ## Solution - Update the version of Taffy - Update code to work with the new version Note: Taffy 0.4 has not yet been released. This PR is being created in advance of the release to ensure that there are no blockers to upgrading once the release occurs. --- ## Changelog - Bevy now supports the `Display::Block` and `Overflow::Hidden` styles.
Is there anything new to announce? |
Closing as adopted <3 |
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):Overflow::Scroll
variant has been added to theOverflow
enum to mark nodes that should be scrollableRequirements from Taffy:
Overflow::Hidden
DioxusLabs/taffy#424 (Correctly lay outOverflow::Scroll
/Overflow::Hidden
nodes)Overflow::Scroll
DioxusLabs/taffy#446 (Support reserving space for scrollbars forOverflow::Scroll
nodes)Tasks
Overflow::Scroll
variant toOverflow
enumScrollPosition
componentupdate_scroll_position
systemOverflow
in each axis (Split UIOverflow
by axis #8095)ScrollPosition
component optional for ui nodes to avoid checking every node on scrollChangelog
Overflow::Scroll