Improve the ButtonGroup experience in editor?

[tprobinson]

Hello, relative Godot newbie here. Having made a radio button list for the first time today, I was somewhat annoyed with the experience of using ButtonGroup. The examples I can find all suggest instantiating and connecting signals in code, but this feels like something that would be relatively easy to improve in the editor.

As it is, the "Button Group" field is accessible in the editor and lets you make a new ButtonGroup. But the only way to assign other buttons to the same group is to save it as a resource (making an unnecessary Resource file, since there's nothing customizeable about a ButtonGroup) or to duplicate the button. Or edit the scene file I guess.

Once multiple buttons are assigned to the same group, there's no way to connect the pressed signal while in the editor-- right-clicking the ButtonGroup and choosing Edit lets you select specifically the group, but then choosing the Node tab just shows the blank "Select a single node to edit its signals and groups" readout. I think this is because it's a Resource and not a Node? But I'm not sure.

I feel like this is so close to working in the editor. The alternative of having to assign all the buttons to groups, then in my scene's _Ready() function give them a new ephemeral ButtonGroup, then hook up the signal, is pretty lame.

If an editor UI solution isn't the best here, perhaps it would be a bit heavy-handed, but maybe a new Control-type node could be made that wraps multiple Button-type nodes, and can emit a .pressed() signal in the same way ButtonGroup does?

[Calinou]

But the only way to assign other buttons to the same group is to save it as a resource

You can use the Copy button in the resource dropdown then Paste in other locations to use a built-in resource multiple times in the same scene. This can't be done across different scenes though, unless the subscene has Editable Children enabled and you give it the built-in resource from the parent scene in the editor.

Once multiple buttons are assigned to the same group, there's no way to connect the pressed signal while in the editor-- right-clicking the ButtonGroup and choosing Edit lets you select specifically the group, but then choosing the Node tab just shows the blank "Select a single node to edit its signals and groups" readout. I think this is because it's a Resource and not a Node? But I'm not sure.

ButtonGroup is a resource, not a node. Resources don't have signals you can connect. The button_pressed signal is still part of the Button node, even if the Button is part of a ButtonGroup by virtue of having a ButtonGroup resource assigned.

If an editor UI solution isn't the best here, perhaps it would be a bit heavy-handed, but maybe a new Control-type node could be made that wraps multiple Button-type nodes, and can emit a .pressed() signal in the same way ButtonGroup does?

The reason it works with resources instead of a child node setup is to avoid imposing a certain scene hierarchy (which has an importance when using containers). This matters because buttons that are part of a ButtonGroup aren't always right next to each other.

Godot 2.x used a node-based ButtonArray system and it suffered from this limitation if I recall correctly.

[tprobinson]

Thanks for the reply! Good to know about the copy and paste, I knew that worked for some properties but I didn't know it works for resource selection. And it makes sense to avoid that hierarchy problem you were talking about.

ButtonGroup is a resource, not a node. Resources don't have signals you can connect. The button_pressed signal is still part of the Button node, even if the Button is part of a ButtonGroup by virtue of having a ButtonGroup resource assigned.

I do have to disagree about this though-- the ButtonGroup itself emits a pressed(BaseButton button) signal (docs), which is part of what I found to be convenient when I was using it initially. I don't know if this is just a weird exception or something, and that's why the editor doesn't account for it?

But at least, knowing the easier copy-paste method of getting a ButtonGroup into multiple Buttons, the code solution becomes more simple:

GetNode<Button>("Button").ButtonGroup.Connect(ButtonGroup.SignalName.Pressed, this.ButtonGroupPressedCallable);

Still, since other signals can be connected in the editor, it would be nice to be able to do that in the editor here too. Maybe some kind of UI hint about being able to copy-paste a ButtonGroup when you click on it, since that seems to be the nicest solution to ButtonGroup-as-a-Resource? I dunno.

[alakoring]

You can use the Copy button in the resource dropdown then Paste in other locations to use a built-in resource multiple times in the same scene.

Can this be mentioned in the ButtonGroup documentation? I was running into the same issue (how to hook up a set of radio buttons) and if not for this note, I would have been stuck (or made the redundant resource).

[Kartopod]

Note that you can also select any property in the editor, use Ctrl + C to copy the property value, and use Ctrl + V with another property selected to paste that value

[tprobinson]

I tried to use ButtonGroup again and hit another weird problem with it. In the case I'm using them for now, it's for a set of timescale buttons like you see in games like SimCity or Rollercoaster Tycoon: pause, play, fast-forward, super-fast-forward. I wired a ButtonGroup to all of them, set their container's ProcessMode to be Always, and thought that would be fine. Unfortunately, when I hit the Pause button, suddenly all the buttons stopped responding.

After some debugging I realized that because a ButtonGroup is a Resource and not a Node, it doesn't have a .process_mode. So it doesn't inherit the Buttons' capability to continue processing when the game is paused, and stops emitting signals despite the individual Buttons themselves continuing to work. I can't manually set its process mode via the editor or code, because that property just doesn't exist on it. So I'm starting to come to the conclusion that the ButtonGroup-as-a-Resource is just not a good implementation of the radio-button concept.

To keep it as a Resource but improve its usefulness, it would need to continue receiving exceptional behaviors that make it behave like a Node (emitting signals, process mode, etc) , but not actually be a Node so it doesn't interfere with layout flow like the previous ButtonArray problem. Implementing my previous suggestions for improving the editor experience with it would also require a bunch of exceptions to the typical flow. I'm not a C++ developer, but that sounds like a maintenance nightmare to me.

Overhaul ButtonGroup?

Since the Node-based approach hasn't worked in the past, and the Resource-based approach has a bunch of awkward downsides as well as a future of painful exceptions, maybe I could suggest something similar to what HTML does? In HTML, button tags that are type="radio" treat the name attribute as their "group". All buttons that have the same name get grouped together in radio button behavior.

In Godot, that might be best implemented as a string property on BaseButton, called something like "Group Name". If that property is defined, then the button goes into radio-button mode. When pressed, any . On BaseButton, make the ButtonGroup attribute a string. If the string is defined, then it goes into radio-button mode.

This is where I especially can't speak to the implementation details, but in C# language, I'd say you'd want a static dictionary on the BaseButton class that Buttons with the "Group Name" defined register and un-register themselves in. Probably would want to subdivide that dictionary per-scene, to make those names local to each scene? Or maybe there could be a toggle to have a group name be scene-local or global, for niche use cases. Then when pressed, any grouped button could un-press other buttons in its group.

As for signals, I don't know what would be more in line with what the rest of the engine does: having a signal be emitted from the static BaseButton class (like BaseButton.group_pressed(string group_name, BaseButton btn)), or having each Button emit something like a .group_pressed(BaseButton btn) signal. Or perhaps there's another option that would work better there.

Since now I'm suggesting to change the whole resource, maybe this topic should be moved to a different category? But either way, hopefully some of that was good food for thought!

[aXu-AP]

Hard to see how that would be implemented in compatibility preserving manner.
There's quite big push to move away from string-based features so you might have hard time getting people behind this idea (for example, earlier connecting signals was like animation.connect("finished", "queue_free"), now preferred way is animation.finished.connect(queue_free))
Other than that, I think that your idea is easier to grasp than the current way with resources!

[ajreckof]

In Godot, that might be best implemented as a string property on BaseButton, called something like "Group Name". If that property is defined, then the button goes into radio-button mode. When pressed, any . On BaseButton, make the ButtonGroup attribute a string. If the string is defined, then it goes into radio-button mode.

First thing this type of modification is compat breaking and thus can't be done lightly (no chance until Godot5 I think here)
In fact if you wish to do that it would be really easy in GdScript and wouldn't need to add it to the engine. You just need to create a script inheriting BaseButton that hides the button_group variable and create a button_group_name variable. assign button_group based on the value of the variable through a dictionary that map names to buttonGroups. Then when you want to have you radio buttons you just need to add the script to the relevant button

[tprobinson]

Oh yeah I figured there was no way this would be a "soon" kind of thing, lol. But that script sounds like an interesting workaround for the time being, think I'll try it!

[aXu-AP]

One way you can easily assign buttons to the same group is by selecting the buttons and then create the ButtonGroup: