proposal for custom layout solvers

[Niedzwiedzw]

DRAFT

Objective

There's been some talk about providing a way to define your own layouts, this would enable this

[nicoburns]

I'm definitely open to a feature like this, however:

• Why have you introduced so many Boxs? I think it should be possible to implement this without boxing.
• I think we'll want Display::Custom to work like measure functions and be a single function passed to a compute_layout_* method, for the same reason that measure functions work like this: it allows them to borrow external context. I think the main difference between this and measure functions is that custom layout would need to be able to size and position children.
• We should think about whether we need both measure functions and custom layouts or whether this should replace measure functions.
• Not sure what I think about the "name" parameter. It seems fine, but it may be better to replace it with an ID or just rely on the node context.

[Niedzwiedzw]

Why have you introduced so many Boxs? I think it should be possible to implement this without boxing.

yeah thing is this is the only way to make that trait a trait object and I didn't want to make Display generic over Tree: LayoutPartialTree cause that way Style would also need to be generic over that etc...

[nicoburns]

Why have you introduced so many Boxs? I think it should be possible to implement this without boxing.

yeah thing is this is the only way to make that trait a trait object and I didn't want to make Display generic over Tree: LayoutPartialTree cause that way Style would also need to be generic over that etc...

Ah, I see. I think this can be solved by making the custom layout function something that is passed in to the call to layout() similar to layout_with_measure. This means that the type only needs to exist in the function signature (and the TaffyView struct) and can be implemented as a generic (and as a bonus allows that function to (mutably) borrow external data if it wants to). Measure functions used to be stored within the Taffy struct similarly to your implementation here but this was changed for these same reasons.

[Niedzwiedzw]

@nicoburns are there any news on this? I'd happily modify this to conform to the API you describe, but question is would it go upstream :D