stararawn / woodpecker_ui Goto Github PK

Was trying to get woodpecker to work with a 2d camera for the ui and a 3d camera for the game, so tried using RenderLayers and:

It looks like bevy_vello doesn't currently support RenderLayers: linebender/bevy_vello#58

it has a PR open for multi-camera support though, which seems blocked only by merge conflicts: linebender/bevy_vello#49

maybe related to/mergable with #13

Currently scrolling is a bit laggy when you have lots of widgets. This is because child widgets get re-rendered when you scroll(scroll widgets change). I can think of two possible solutions to fix this:

1. Have a mechanism for telling Woodpecker to ignore child changes.

Pros:

• Widget diffing works as expected.
• Widgets keep ownership of state.
• Might need this anyways in the future?
  Cons:
• Need to expose this new API somehow.
• Really a bypass to the way woodpecker functions.

2. Pull state outside of the widget structure/update and update styles in a separate bevy system.

Pros:

• Simple bevy system updates widget styles.
• No re-rendering so children never re-render
  Cons:
• Widgets don't keep state
• Every UI element that renders to the screen will need to be controlled by the bevy system meaning that they will update in both the widget and in the bevy system. References to the entities will need to be passed around.

Repo

I've extracted a custom TransitionTimer and Button widget to a repo for reproduction: https://github.com/ChristopherBiscardi/woodpecker_buttons_repro

Behavior

By default in the repo, because there is a mutation of WoodpeckerStyle from the main_menu_interaction system, the Transitions re-occur constantly, seemingly due to re-initializing the values which in turn causes the timers to run, etc.

commenting that single line out shows a different behavior, that only re-starts the Transition when the window resizes.

From an implementation point of view, this style update is unrelated to the Transition behavior and should not cause the TransitionTimer to re-start.

Desired Behavior

I want to animated two solid color bars across the area the button will show in, spawning in the button behind these bars during the animation similar to a "stinger" transition. Once the Transition is over, I never want it to happen again.

Additionally, I want to have hover states affect the styles on the button after the Transition is over. Implementing these hover states is where I started to run into issues (specifically, the style mutation).

More details

The goal of the button is to play two solid color bars across the button surface area the first time it renders, revealing the content underneath. It currently achieves this through a custom TransitionTimer component that accepts a vec of styles and a vec of timers. Each element in the widget is then animated multiple times using these timers, lerp, and a mutation of the WoodpeckerStyle (basically the same logic as the current built-in Transition).

In a future implementation, I'd like this "Stinger" entrance behavior to be its own encapsulated behavior that I can add to a variety of widgets. I'm probably also going to try to take advantage of clipping so that the reveal is all left-to-right whereas currently it is first block left->right, second block left->right, second block right->left.

Questions

In React (and some other UI frameworks), the render function re-runs any time there are props or state updates. This is not the case when the WoodpeckerStyle component is updated, so there is clearly a "second render function" to think about (ie: vello) from that perspective. What is the mental model for the Widget::render function given these additional rendering updates, and in conjunction with the new hooks/state functionality?

I think answers to that then follow on with "should TransitionTimer and PickingInteraction drive widget state" and "how do arbitrary Component values on the entity relate to props/state/etc and when should each be used".

• Make sure our camera queries are agnostic to the camera type.
• Make sure we can support multiple viewports/cameras.

Vello should provide this out of the box we just need to hook it up

bevy_vello supports these we can too!

This just pertains to clearing out the bundle by calling WidgetChildren::clear().

Todo examples really show a full fleshed out UI and help squash bugs. Lets make one!

(Requires #9)

Widget context should exist local to the tree where it is spawned. API example:

// parent.rs
let context_entity = api.use_context::<T>(current_widget);
commands.entity(context_entity).spawn(MyContext);

// child.rs
let context_entity = api.use_context::<T>(current_widget);
let Ok(context) = context_query.get(context_entity) else {
    return;
}

Sometimes scrolling can flicker when you scroll, I think this is caused by a weird issue where the layout tree sets a height to be the size of the scrollable content but then rights itself the next frame causing a flicker.

Taffy API is kinda gross. Also the taffy types conflict with bevy types. Ideally we just have our own style types and convert to taffy types as needed. This also lets us extend and add rendering types like: background color, font size, font color, etc.

• Textbox
• Window
• Scrollbar (requires #10 )
• Image
• Modal
• Toggle
• Table
• Slider
• Dropdown
• Checkbox
• RadioButton
• Tabs

Just need to figure out how to grok the types into playing nicely.