Add event for clicks

[Shatur]

Objective

• Rebase to the lastest main for Add event for clicks #9240.
• Add click events that capture the press release cycle of a UI node being clicked
• Addresses Add event for clicks #9047

Solution

• Add API to send Click events when an Interaction goes from Interaction::Hovered to Interaction::Pressed.
• Incorporate Click event sends into UiPlugin by default.
• Refactor game_menu.rs example to use Click rather then manually checking the Interaction.

---

Changelog

Added

• Click events when an Interaction goes from Interaction::Hovered to Interaction::Pressed.

[alice-i-cecile]

Can you say more about why this is a better pattern? What problems is this solving, and why should we add another way to do this?

I think that our "UI interaction" model is very half-baked, but I'm not yet sold that this is the right fix.

[Shatur]

Can you say more about why this is a better pattern? What problems is this solving, and why should we add another way to do this?

Interaction::Pressed is a button state. It's useful for changing button style, for example.
But a click in a UI is not a state, but an event where the button is released while the cursor is still on it.
So using Clicked event is not the same as checking for Interaction::Pressed. Without this PR implementing "conventional" clicks will require users to create their own component that tracks previous state and compare if state changed and the previous state was Interaction::Pressed. So it's a lot of boilerplate to do it without it.

[killercup]

Not sure "clicked" conveys the right meaning, as the name doesn't imply it's on release. The Web API's click event is only emitted on release just like you implemented it here, though.

[Shatur]

I think clicks in any UI always works this way. But won't hurt to mention in the docs, of course!

[JoJoJet]

Yeah, "click" is the right terminology here. We have "pressed" as a one-phase event, "just pressed" as a two-phase event, and "clicked" as a three-phase event.

[UkoeHB]

This PR improves the existing implementation a bit, but in the long run this code needs to be completely replaced with a solution more similar to bevy_mod_picking.

[Shatur]

This PR improves the existing implementation a bit

I would like to clarify that this PR doesn't improve or change any behavior. It just adds an event for proper "clicks". Interaction::Pressed is not the same. I would use Interaction::Pressed for things like style change and click events for actual logic.

[rparrett]

I just want to link another PR with a similar goal and different strategy. #8157 which adds to the Interaction enum. Not taking a position either way. edit: some great discussion in #7371 about yet another potential approach involving Interaction.

This is technically non-breaking but it is beginning a design for a very core aspect of bevy_ui, and it feels awkward in code to mix the two styles to me. It seems possible to implement in a plugin and is very likely to change significantly (see #9538).

So I think I am not in favor, but I don't feel strongly about that.

[Shatur]

I just want to link another PR with a similar goal and different strategy. #8157 which adds to the Interaction enum.

it feels awkward in code to mix the two styles to me.

I saw it. But I think that "released" not a state, it's a state transition from Interaction::Pressed. It's a one-time thing, why change button to Interaction::Released for one frame?
Interaction best suited for changing button styles, clicking from this PR - for button logic. Otherwise what style should button have when Interaction::Released? If the same as Interaction::None, colors will flash for a single frame if you keep your cursor on the button. This is why I think that using event is a more ergonomic way.

It seems possible to implement in a plugin

Sure, but it requires only 6 new lines of code logic inside Bevy, this is why I decided to suggest it.

and is very likely to change significantly (see #9538).

Looks like logic will be event-driven, so this should play nicely with the upcoming rework.

[shanecelis]

Hi, I got surprised by the pressed behavior on buttons not being click. I realized thanks to @Shatur's comment that click is a transition and instead of adding Released, we can just look for the transition from Pressed to Hovered. The code for that is short and simple.

/// Excerpt from this gist[1].
///
/// * * *
///
/// A trigger event that signifies a click on a button.
///
/// ```
/// # use bevy::prelude::*;
/// # use bevy_asky::view::click::{self, Click};
/// fn setup(mut commands: Commands) {
///     commands.spawn(ButtonBundle::default())
///         .observe(|trigger: Trigger<Click>|
///             eprintln!("Clicked on {}", trigger.entity()));
/// }
/// ```
/// [1]: https://gist.github.com/shanecelis/06b2d1a598e1e06d0a00671596e9f74f
#[derive(Event, Debug)]
pub struct Click;

/// This system looks at [Button] [Interaction] changes. If that state changes
/// from [Interaction::Pressed] to [Interaction::Hovered] then it will trigger a
/// [Click] event targeting the Entity with the [Interaction] component.
///
/// TODO: The `Local<EntityHashMap>` should be reset or drop elements that are stale
/// so it doesn't grow unbounded.
fn button_click(
    mut interaction_query: Query<(Entity, &Interaction), (Changed<Interaction>, With<Button>)>,
    mut last_state: Local<EntityHashMap<Interaction>>,
    mut commands: Commands,
) {
    for (id, interaction) in &mut interaction_query {
        let last = last_state.get(&id);
        if *interaction == Interaction::Hovered && matches!(last, Some(Interaction::Pressed)) {
            commands.trigger_targets(Click, id);
        }
        last_state.insert(id, *interaction);
    }
}

[alice-i-cecile]

Closing in favor of integrating this functionality into the now-upstreamed bevy_mod_picking.