Some way to access the child of a SizedBox and a Container

[smmalis37]

I created a widget with the code Label::new("foo").with_text_color(Color::BLACK).border(Color::BLACK, 0.5) and needed to store it somewhere. The return type of this builder was Container<String>, so I made a field of that type, stored it, and moved on. Later I wanted to be able to dynamically change the text color of the label, but I couldn't find a way to access this property through the Container. It would be helpful to have a .child() getter or similar to enable this sort of usecase. Maybe even a Deref impl, although that might be too much.

[luleyleo]

Maybe you could use Env for this? I.e. create a custom Key for the color and set that as the text color, then use an EnvScope to change to color dynamically.

Something like .child() does not work really well with Druid as we have no explicit widget graph.

[cmyr]

the broader feature of "accessing the concrete child of a layout widget" is definitely something that it would be nice to have. I've experimented a few different ways but haven't ever gotten something that felt compelling; in particular we would want this to work for multiple children, e.g. we would want you to be able to reach past a Padding and a Container to the inner concrete widget.

[smmalis37]

One alternative could be to change methods like .border to return the same Widget (i.e. Label::new().border() still returns a Label, and Button::new().border() returns a button) instead of a container. I have no idea how things are implemented, so I don't know if that's feasible at all, but it'd eliminate (or at least severely lessen) the need for .child.

[cmyr]

That really isn't an option, unfortunately, or at least not without sacrificing the composability that is one of the main justifications for the widget model we've adopted. 😢

[rjwittams]

The trait BindableAccess in my binding-scroll branch solves this (so you can e.g bind the underlying widget through a lens or more layers of wrappers). It needs trivial implementations of Bindable on leaf/bindable widgets and BindableAccess on wrappers, . There are some limitations at the moment like not being able to reach through to multiple different bindable things at different levels ( E.g. a lensed scroll containing some other widget will stop at the scroll as it is bindable), not sure if that will be an issue in practice, and it may be solveable with more work.

Having said that I mainly used it during construction, where you may still need to reach past lens wrappers etc. My current answer for how to fiddle with widgets after construction would be bindings themselves. In this case I’d have the text color somewhere in the app state, and bind that color to the color field of the Label struct (although it would likely be a generated bindableproperty that invoked the necessary request_paint etc). This is pretty much a text book use case for bindings.

[rjwittams]

https://github.com/rjwittams/druid/blob/eab05745f70f29d0aac8f5f257f13fe96165b0ca/druid/src/widget/binding.rs#L13

Only need to look at the first 40 lines or so. The rest is bindings themselves!

[smmalis37]

So I've tried changing my code to the following (simplified):

const COLOR_KEY: Key<Color> = Key::new("color-key");
Label::new("foo")
.center()
.env_scope(|env, data| env.set(COLOR_KEY, if data....))
.background(COLOR_KEY)
.border(Color::BLACK, 0.5);

however this panics immediately on launch, saying thread 'main' panicked at 'Missing key: 'color-key''. Am I doing something wrong?

Additionally, this seems a little silly to me to set a value and then immediately access it. Would it make sense to allow a closure to be passed directly to with_text_color to just return a Color, similar to how Label::dynamic works? KeyOrValueOrClosure just rolls right off the tongue, doesn't it?

[smmalis37]

After looking into it a bit, I don't think KeyOrValueOrClosure can really work, as it would have to add another generic parameter for the type of data being passed to the closure, and that makes them much less reusable.

[cmyr]

in your example, the container is outside of the env scope; if you switch the positions of env_scope and background this should work.

You can customize the Env at launch with AppLauncher::configure_env. Also check out the env chapter in the book if you haven't already.

I've actually been experimenting with something for synthesizing values from the environment, similar to your KeyOrValueOrClosure idea, if I'm understanding correctly.

[smmalis37]

I don't think it would be if I'm understanding you correctly, because my idea isn't about using just env, but also data. What I was thinking is it would be nice if we could have apis similar to Label::dynamic, where the value they need is determined by calling a closure, but everywhere. Every function that currently takes an Into<KeyOrValue> could alternatively take a closure over the data of the widget in order to compute the text size, or background color, or whatever. The problem is this necessitates adding another type parameter to this new KeyOrValueOrClosure for the type of data that the closure is passed, which I figured was a non-starter. For an example of what this could look like:

Label::dynamic(|data, env| data.string_val)
.with_text_color(|data, env| if data.green { Color::rgb(0.0, 1.0, 0.0) } else { Color::BLACK })
.with_text_size(|data, env| data.magic_number * 12.5)
.background(|data, env| if data.get_background_from_env { env.get(BACKGROUND_KEY) } else { COLOR::WHITE })
...