doesn’t have to be addressed now, but just a future note that if you happen to create an example that uses both this new checkbox helper and the radio helper, ci might complain that one of the main_ui_node_scene() helpers in either file isn’t used (since presumably you’d only be using one of them). you can cross that bridge when you get there (or you can do something about it now if you wish)

I'll address this now! Would it be worth it do you think to extract main_ui_node_scene from radio.rs out into a separate scene.rs helper? We could have a few different canonical scene constructors with different screen positions (top_left, bottom_left, etc).

A separate helper file makes sense yeah! And you can rename the function to bottom_left_scene() or something if youd like. I like your idea about specifying the potential different positions for potential control settings, but you can just stick to extracting out the single shared one for now -- dont need to overengineer it at this point

Okay cool. I added that. I did add a top_left_scene as well, only because I wanted to use it in this particular example for wasm builds. I think it's a better ux in browser to place the checkbox in the top left of the screen since then when the page loads it's immediately obvious what controls are available, whereas if placed in the bottom the user has to scroll down to see them.

I didn't touch the main_ui_node_scene function in radio.rs or any references to it. I can submit a separate PR updating those?

sounds good for a separate PR, nice thinking :)

I tested in wasm and this breaks the example because this param is not available in that target_arch

I’d recommend you walk through testing in wasm yourself too just to see what happens / try out debugging

I think this can be simplified to just one cfg call within the CheckboxInput::Wireframe match itself for #[cfg(not(target_arch = "wasm32"))]

i.e.

            CheckboxInput::Wireframe => {
                if !cfg!(target_arch = "wasm32") {
                    wireframe_config.global = !wireframe_config.global;
                }
            }

Hmm that throws an error since the Wireframe2dConfig is removed at compile time by the #[cfg(...)] gate on use bevy::sprite_render and since the cfg macro doesn't remove any code at compile time (TIL) the compiler still requires wireframe_config to be defined somewhere

You’ll have to update this comment

I tried rebasing and dropping those commits from this branch instead of PRing anew. @kfc35