druid: Problems with TextBox::fix_width()

It’s tricky. Your position is basically “make the API hard to use, forcing the developer to confront the complexity.” My position is “make the default choice the one that is most likely to be correct, and move the complexity to a separate method”.

There was an intermediate design that was as you describe (with the exception that children can have more than just their flex factor customized; see FlexParams; it’s now just flex and alignment, but it used to include a few other things like loose/tightness of flex, and it might grow in the future) (#639) and ultimately it just didn’t feel good. This solution felt less bad, but I’m still not especially happy with it; but I’m yet to hear anything that feels clearly better.

In any case, we’re of course free to disagree on this! It’s a subtle matter of priorities and philosophy, and I can see the value of either position. This API ended up winning out at the moment, and I’m not especially interested in breaking the API again until a clearly better approach surfaces. 🤷

This stuff is definitely nuanced and not always intuitive; the Flex widget docs are definitely worth going over, and it’s very possible we should have a few more examples in there.

I believe we should change the behaviour of Flex, because this seems rather unintuitive to me.

But even in this world they would have to decide which variant of the enum to use in a given circumstance, which means they would still have to know how this works, which means they’d have to go read the docs. This would also require the caller to import another type into scope, which isn’t the end of the world but is definitely something I would want to justify.

I think it is going to be difficult for someone to use the flex layout system competently without reading the docs and looking at the examples (the flex example is also something I put a lot of time into). It feels to me like we’re trying to find some API that is simple and intuitive and also expresses all of the underlying complexity, and having spent a number of weeks thinking hard about this I’m just not sure there’s a solution.

This was true initially; there was a single method, and you passed a flex factor, with 0 for no flex. The result there was that people would consistently pass 1.0 for the flex factor, which also is not what you generally want.

The current API is based heavily on flutter, which defaults to non-flex children and has a separate API for flex children. This was all workshopped heavily in march; the most relevant discussion from then would be #691 #639 and #607.

I’m still not totally happy with this API! It is confusing, but there is also substantial underlying complexity, and I doubt there is a simple API that will work as expected in most cases. I do think that the flex docs are quite good, although I’m very happy to hear suggestions for how things could be clearer.

I believe that by default, in a row or column, you do not want items to be flex; this was a major cause of pain in earlier revisions. It may be that naming the container Flex is a source of confusion, and we could consider changing that, but I’m not sure how to make the docs much clearer, any suggestions welcome!

I agree that it seems reasonable to assume that add_child is the “default” method to use. I remembered there being an issue with some more context which you can read here.

Just chiming in that I also hit similar confusion here from just reading the docs. I assumed that Flex::add_child would add a child and flexibly size it, and was very confused when it didn’t. I skimmed the docs and saw add_flex_child, but after reading the sentence “This method is used when you need more control over the behaviour of the widget you are adding.” stopped, because I don’t need any additional control. I just wanted 4 things that were equally sized and took up all available room and assumed that was the default behavior (as it has been in some other ui toolkits i’ve used). Eventually I figured out that I needed to call add_flex_child(foo, 1.0) for everything and it all worked out.

I think the existence of the two separate methods is confusing here. add_child sounds like it’s the default, and given that we are in a Flex I initially expected everything to have a flexible size. It seems both MGlolenstine and I fell into that trap. My suggestion would be to only have a single add_child method, with a second parameter that’s an enum of FixedSize and Flex(f64) or something.

Oh, those are great ideas! I’ll check them out on Monday when I’m back at work 😉

Thanks for the help!

Would be helpful to have a minimal example to reproduce the issue.