Delete Callback and use observers to control widgets for 0.17

[viridia]

Removed the Callback type.
Updated all widgets and examples.
Added an observe helper which adds an observer via a bundle effect.

Note: I would have updated the release notes, but they are gone already.

[alice-i-cecile]

I take it you're interested in shipping this for 0.17 then?

[alice-i-cecile]

We really need to rethink this example, but I can do this in follow-up.

[cart]

I'm not sure theres much to do here outside of adding support for multi-event-observers. Curious to see what you come up with though!

[alice-i-cecile]

My complaints are mostly that this example is very poorly motivated pedagogically, especially if we're using observers for behavior by default :)

[viridia]

I take it you're interested in shipping this for 0.17 then?

I realize that this is very last-minute. However, I really, really dislike the idea of shipping callbacks to our users and then doing an immediate rug-pull on them - "oh, all that callback code you just wrote? You can throw it away now."

[janhohenheim]

Not any deep feedback yet, other than:

• I love this at a first glance
• I would encourage taking a look at the prior art of the observe function before merging this. Or even better, get a review in from the authors!
  • https://github.com/benfrankel/bevy_spawn_observer/ by @benfrankel
  • https://github.com/tim-blackbird/bevy_observers by @tim-blackbird

[alice-i-cecile]

I'm morally on board, but I'd like to do a review

• @cart on Discord

[alice-i-cecile]

Previously attempted in #18975 and #19613.

[benfrankel]

Generally looks good to me, the API feels more natural with observers.

[PPakalns]

Read code changes and successfully tested widget integration into bevy_immediate.

New approach looks a lot better.

• It is very nice that self update logic is now opt-in. It is easier to integrate these widgets into a library that links program state together with UI.

This is a huge improvement, I think this should be released in bevy 0.17 as it is easier to use and sets better example for future UI development. 🎉

I still do not like how Radio widgets and RadioGroup works. It would be better for each widget to have separate events. But I could partially override behavior with my own. RadioButtons and RadioGroup shouldn't make assumptions that there is exactly one active radio button.
But that is out of scope of this PR and discussion.

[alice-i-cecile]

First impressions as I review this:

• I really appreciate that we're able to remove fields for things like click_handler. This makes it easier to add multiple responses to interaction events and makes spawning much cleaner (and more compatible with an asset-driven workflow).
• I agree with the TODO for virtual keyboards: good to fix, but fine to punt
• observe has nice ergonomics, even though it's a bit magical. The existence of multiple independent reimplementations suggests that there's a real need for this! I think we can move and should move this to relations in 0.18
• Noticed that we don't support gamepads here when we should: opened Add gamepad support for feathers / headless widgets #21260.
• Mild preference for just putting observe and friends directly into bevy_ecs: it's widely useful and that's clearly the "correct" home for it. Let's see what @cart rules though: I can live with this for a release.
• boy do I like not having to pass in &mut Commands into the impl Bundle constructors
• the ergonomics of defining callback behavior via observers in this fashion is much better. Way less boilerplate. I really hated having to register systems for this.

Deeper thoughts:

1. We're still leaking: just observers rather than callbacks. Swapping to relations should resolve that cleanly.
2. This makes it harder to reuse callbacks (in terms of allocated structs, not code) across widgets, as we're doing a strict one-observer to one-widget design. I'm not particularly concerned about that: buttons which have a
3. I think that passing in extra input information via fields on events is much more natural to users than dealing with system piping (as cool as it was to see a serious application of it).
4. I appreciate that it's much easier to piggyback on various events now: system piping is totally opaque.
5. The swap to observers makes it much easier to get supplementary information like "what entity was this targeted at", which should ease refactoring.
6. Clearly splitting apart "config" from "behavior" (e.g. the changes to Slider) into different elements of the template should make composition, inspection and diffing easier in the future.
7. We are really going to need tooling for tracking observers as we scale this up.

[alice-i-cecile]

I think this is a solid improvement to ergonomics and complexity, and we should merge it for 0.17. I'm happy with the implementation of this, and I've tested the feathers example: everything seems to be working as intended.

observe isn't a perfect solution, but it's much closer to what I think we should be using in the long term and has a clear migration path.

Like I said above, I'll defer the decision on where observe should live (and how widely we should encourage its use for 0.17).

[Pascualex]

From Alice:

(and more compatible with an asset-driven workflow)

I think this is very important. It has never been clear to me how the design patterns that work on React functions (inputs/props) would work once we replace most of our scene functions with scene assets.

I really like the new approach and will like it even more once #17607 is done.

[cart]

I think it should be unsurprising that I'm on board for this, given my campaign here. Very happy with how this turned out.

I like that the mechanism for controlled vs uncontrolled is simpler and more explicit.

@PPakalns

It would be better for each widget to have separate events

Strongly agree here. This was my takeaway as well, and it is the pattern I would like to encourage in general. I don't think we need to do that for 0.17 / in this PR, as we're already getting this in last minute, and this is still "experimental".

@alice-i-cecile

I'll defer the decision on where observe should live (and how widely we should encourage its use for 0.17).

I strongly believe that we should not move observe to bevy_ecs as it violates the "non-component things should not masquerade as components" principle. I've held that line up until this point, and I will continue to do so. This is what bsn! is for.

I view including observe here (hidden behind the experimental flag and scoped to the widgets work) as a targeted "middle ground" compromise in the interest of not hamstringing the UX of this work while we wait for bsn!.