Use environment system to wire up a radio_group context with radio_buttons

[Philipp-M]

This is a very dirty draft/idea that takes into account ideas of #xilem > Simplify checkbox?
and the idea proposed in linebender#1428
So don't look too close into the code yet, I'll clean this up, when this is a viable direction.

I'll try to explain how this works on a higher level, to hopefully save you some time skimming/reading the preliminary code:

This is logically similar as Provides and WithContext, i.e. the radio_group "provides" a function pointer (mostly to avoid all the issues with generic Fn traits as this type needs to be known in different places of the view tree) to access a value, and radio_button accesses this function pointer to get the current value and potentially modify it when a RadioButtonToggled event occured.

Checkout the updated to_do_mvc example to get an idea how this looks in practice.

There were some hacks necessary (e.g. in xilem/src/driver.rs) which might need some discussion.

Worth of discussion is also whether we want to use a function pointer, I might overlooked something, but the main "drawback" compared to e.g. Fn would be non-capturing, which I think is acceptable (as I don't think it's too clean anyway to capture values here).
Another point would be whether we want to directly provide this functionality in masonry, I've decided against this for now, as I think it would be more complicated, and might not even be something that we want there (too opinionated abstraction at this level?)

(Ignore most of the changes in xilem_core these were mostly shortcuts, to be able to copy/paste a lot of code without modifying too much, just to get a quick idea, though it hints, that we might want to provide some abstractions for this, as there's quite a bit of code-duplication between the mentioned core views)

CC @DJMcNab

[ricvelozo]

Cool! This will be useful for a drop down widget in the future too.

[Philipp-M]

An alternative way would be to use Action, but then we are limited to this type of Action in the view-tree within the radio_group, and views like a button whether they make sense within a radio_group or not need to return the type of action that the radio_group defines.
(and I wanted to explore whether the environment system makes sense for this, as this could open up other things like cascaded styling etc.).

I think either way is good for me, the advantage of using Action for this, is that we can use Fn instead of a function pointer, and that all the boilerplate for using the environment system is not necessary (although I think that could be hidden somewhat by providing abstraction for this kind of use-case).
Might be cleaner. Though well... it's trade-off space

[ricvelozo]

An alternative way would be to use Action, but then we are limited to this type of Action in the view-tree within the radio_group, and views like a button whether they make sense within a radio_group or not need to return the type of action that the radio_group defines. (and I wanted to explore whether the environment system makes sense for this, as this could open up other things like cascaded styling etc.).

I think either way is good for me, the advantage of using Action for this, is that we can use Fn instead of a function pointer, and that all the boilerplate for using the environment system is not necessary (although I think that could be hidden somewhat by providing abstraction for this kind of use-case). Might be cleaner. Though well... it's trade-off space

I didn't quite understand the Action limitation, but in real-world scenarios we can expect complex hierarchies of radio_group & checkbox, like in wizards: https://tutorials.ptnetacad.net/help/default/images/activityWizard_initialNetwork_3.jpg

[ricvelozo]

Also, off-topic: I was thinking these days to use the environment stuff to broadcast "live" system settings, like color scheme or standard keyboard shortcuts.

[Philipp-M]

An alternative way would be to use Action...

On another thought, I don't think it's really (easily) possible, we need to get the value of the radio_group via the access_value function, which we somehow need to be able to access...

I didn't quite understand the Action limitation.

What I meant is that the radio_group defines an Action Scope e.g. Filter within all children views (i.e. they would need to have the type impl WidgetView<State, Filter>), the radio_group itself would have a generic Action again. It might be that type hints are necessary as well, but I'm not sure.
Taking the button example, the callback returns Action (which is often just ()) it would now need to return Filter and could potentially set the radio_group value.

But then again, it's not really easily possible, as we need to give the current Filter value to the radio_buttons, and that would likely require either the current value (so additional parameter to the radio_button), or some back-and-forth communication in View::message (which might be interesting, but I think convoluted...)

[ricvelozo]

I see. I tried with Action way before without success (I got assertion errors).