Make Radio Button behaviour modular and consistent with other widgets #21294

PPakalns · 2025-09-30T09:23:12Z

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 · 2025-10-01T02:21:26Z

crates/bevy_ui_widgets/src/radio.rs


-            // Trigger the on_change event for the newly checked radio button
+            // Trigger the value change event on the radio button
+            commands.trigger(ValueChange::<bool> {


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.

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.

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

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

viridia · 2025-10-01T02:29:29Z

crates/bevy_ui_widgets/src/radio.rs

-                    break;
-                }
-            }
+    let Ok(checked) = q_radio_button.get(ev.focused_entity) else {


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.

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.

Fixed in 9806468

viridia · 2025-10-01T02:33:07Z

crates/bevy_ui_widgets/src/radio.rs

+    q_parents: Query<&ChildOf>,
+    mut commands: Commands,
+) {
+    let Ok(checked) = q_radio.get(ev.entity) else {


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.

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.

Fixed in 9806468

github-actions · 2025-10-01T18:35:20Z

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 · 2025-10-03T21:02:29Z

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.

PPakalns · 2025-10-09T14:44:13Z

Added release note and fixed markdown linter errors.

At this moment, github pull request is not picking up 5th commit (1ecf91) from my branch. Hopefully just a delay.

alice-i-cecile

I was intending for a migration guide not a release note. Are these changes really all backwards compatible? I suppose so.

Alright, let's merge this: we might cut this release note in editing but that's fine.

PPakalns · 2025-10-09T18:51:24Z

I was intending for a migration guide not a release note. Are these changes really all backwards compatible? I suppose so.

Alright, let's merge this: we might cut this release note in editing but that's fine.

Oh, sorry, I mixed release note with migration note. Probably because there was nothing to migrate.
If I need to convert it to migration note, I can do that too.

…bevyengine#21294) # Objective Fixes bevyengine#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. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

viridia reviewed Oct 1, 2025

View reviewed changes

alice-i-cecile added this to the 0.18 milestone Oct 1, 2025

viridia approved these changes Oct 6, 2025

View reviewed changes

alice-i-cecile requested changes Oct 6, 2025

View reviewed changes

PPakalns added 3 commits October 9, 2025 17:24

Make Radio Button behaviour modular and consistent with other widgets

dbc1432

Fix bug with event propagation cancellation

434353c

Added release note for radio group and button widget improvements

72b5690

PPakalns force-pushed the radio_button_improvement branch from fe96352 to 72b5690 Compare October 9, 2025 14:25

PPakalns requested a review from alice-i-cecile October 9, 2025 14:26

PPakalns added 2 commits October 9, 2025 17:32

Fix markdown linter error

40d2d46

Markdown lint fix, attempt 2

1ecf910

alice-i-cecile approved these changes Oct 9, 2025

View reviewed changes

alice-i-cecile enabled auto-merge October 9, 2025 18:30

Merge branch 'main' into radio_button_improvement

c0cc34f

alice-i-cecile added this pull request to the merge queue Oct 13, 2025

Merged via the queue into bevyengine:main with commit 0d6cb16 Oct 13, 2025
36 checks passed

	// 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

Uh oh!

Make Radio Button behaviour modular and consistent with other widgets #21294

Make Radio Button behaviour modular and consistent with other widgets #21294

Uh oh!

Conversation

PPakalns commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Testing

Uh oh!

viridia Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

viridia Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

viridia Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Oct 1, 2025

Uh oh!

viridia commented Oct 3, 2025

Uh oh!

viridia left a comment

Choose a reason for hiding this comment

Uh oh!

alice-i-cecile left a comment

Choose a reason for hiding this comment

Uh oh!

PPakalns commented Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alice-i-cecile left a comment

Choose a reason for hiding this comment

Uh oh!

PPakalns commented Oct 9, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

PPakalns commented Sep 30, 2025 •

edited

Loading

PPakalns Oct 1, 2025 •

edited

Loading

PPakalns Oct 2, 2025 •

edited

Loading

PPakalns commented Oct 9, 2025 •

edited

Loading