david-vanderson
No API to affect style of direct or recursive child widgets|gravity does not affect direct children
Coming from CSS Flexbox, this is a bit strange to me.
Having only global default for gravity is strange.
Currently you have to pass gravity to each widget. I think there need to be some way for widgets to get default options from their direct parent (e.g. gravity) and from recursive ancestors (e.g. font size)
Originally there was an implicit Options that you would push/pop stuff onto so it had a recursive nature. And it was really confusing (at least for me). Now the idea is that if you want this kind of inheritance you would thread an Options var through the code, locally using .override().
Still I have wondered if font size should default from parent, but then you run into how to communicate when not to use the parent's font size. For gravity I'm pretty sure the global default is good, because I'm usually thinking of a compound widget where it's gravity shouldn't affect the arrangement of the inside widgets.
Do you have some code that illustrates this that I can look at? A good motivating example could help guide us here.
I changed the title.
Do you have some code that illustrates this that I can look at? A good motivating example could help guide us here.
I don't have a good motivating example. I have a example.
If I use a flexbox and want to align every child in the center, I have to remember to pass the options when I add new children to the flexbox.
The code looks very different, like this
widget(..., grav_options.override(.{}))
because I'm used to write this all the time
widget(..., .{...})
I simply do not trust myself remembering the above code style.
Thanks for the example. When you forget (as I often do) to use grav_options.override, is it at least immediately obvious what happened? Does it take much time and effort to figure out how to fix it?
One design feature I'm really going for is visual feedback - when you add some widgets or change some options the visual output should change obviously (as much as can be). I'm willing to give up some cleverness in the design and require a bit more typing for it. That is what is driving the current design, and I'm worried about introducing non-local dependencies.
Having said that, it only works if it actually makes the coding go well. In light of that, would you be willing to use the current system for a while longer and circle back on this?