Make Radio Button behaviour modular and consistent with other widgets

[PPakalns]

Objective

Fixes #21261

Solution

Changes:

• Detect events directly on radio buttons,
• Make RadioGroup optional,
• ValueChange events are triggered on checked radio button and RadioGroup.

This makes radio button behavior:

• similar to other widgets, where we can observe triggered change directly on widget,
• radio button widget can function separately,
• modular, users can decide if they want to use RadioGroup or want to roll out their own solution.

Current behavior in examples doesn't change with this PR.

Testing

Tested using existing examples. See feathers example, behavior doesn't change.
Additionally, tested in bevy_immediate where widget consistency is useful.

[viridia]

This seems like an odd way to use ValueChange:

• If the value is always the same (true), then we should trigger Activate instead. Activate is meant for widgets whose state never changes.
• Alternatively, we could trigger ValueChange(false) when the button gets deselected because of mutual exclusion. However, that's more complicated because now you would have to pass around the entity id of the previously checked button (which is not a problem here, but might be further down).
  More generally, if we're going to use ValueChange, it should always reflect the current state of the widget triggering it: a listener that only listens to ValueChange should always know what state the source is in. We can't do this if it only sends ValueChange for some state transitions and not others.

[PPakalns]

We can use Activate. But i used ValueChange instead because all other Checkable widgets raise ValueChange event.

And for me it seemed logical to think that RadioButton can only be checked by interacting with it. To uncheck it users need to add other widgets / radio group / logic that can uncheck it.

[PPakalns]

So I would prefer ValueChange<bool> because all checkable widgets use that event.

EDIT: P.S. But activate is fine with me too.

[viridia]

One consequence of bailing out here is that disabled radio buttons no longer consume the SPACE/ENTER keyboard event, instead the event will propagate to the ancestors.

[PPakalns]

See answer to
#21294 (comment)

Currently we have different behaviour for keyboard and clicks which is probably a bug in current implementation.

I used clicks as a reference implementation.

[PPakalns]

Fixed in 9806468

[viridia]

Bailing out here means that a disabled radio button doesn't consume the click event, which will propagate to the ancestors. In other words, it will cause the click to trigger on whatever container entity holds the radio button, which I think is probably incorrect.

I think that disabled widgets shouldn't behave as if the widget was absent; rather, they should behave as if the widget was read-only. This means that they still receive click events, they just don't respond to them.

This is why I used Has<InteractionDisabled> rather than Without<InteractionDisabled> - so that I could detect clicks on disabled buttons and stop propagation on them.

[PPakalns]

I tried to implement behaviour based on the current click implementation for radio group / button.

Current implementation doesn't cancel click event propagation on a disabled widget.

bevy/crates/bevy_ui_widgets/src/radio.rs

Lines 176 to 196 in eac8bc7

	// Radio button is disabled.
	if q_radio.get(radio_id).unwrap().1 {
	return;
	}
	// Gather all the enabled radio group descendants for exclusion.
	let radio_buttons = q_children
	.iter_descendants(ev.entity)
	.filter_map(|child_id| match q_radio.get(child_id) {
	Ok((checked, false)) => Some((child_id, checked)),
	Ok((_, true)) | Err(_) => None,
	})
	.collect::<Vec<_>>();
	if radio_buttons.is_empty() {
	return; // No enabled radio buttons in the group
	}
	// Pick out the radio button that is currently checked.
	ev.propagate(false);
	let current_radio = radio_buttons

I can fix that too in this PR.

[PPakalns]

Fixed in 9806468

[github-actions]

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

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[viridia]

Apologies for not responding on this, I haven't forgotten about it.

[viridia]

Apologies for the delay. I finally had a chance to check this out locally and verify that the keyboard navigation behavior still worked as expected.

[alice-i-cecile]

I'm happy with this now, but it needs a migration guide :) The changes here are quite subtle and won't result in compiler errors.