I would expect all items to have a 0x0 size from the factory since the group calc won't have been triggered by that point. Based on the factory design/implementation, that seems to be intentional.

So if I understand, what we need still is handling for layout-based sizes? And then enforcing only the use of parent model sizes if they're provided?

I am meanwhile quite confused when it comes to sizing in this widget, what should we now do, rely *always* on parent model sizes if they are provided, and if not, try to figure out the item sizes ?
The problem with this stragety is, that in cases where we do not yet have the item ready, we do not know the size, and there we need some sort of size for it. And if we rely on the item sizes, then there is no parent, so also no parent size. So i do not know if this stragety works for us.

In T8197#141657, @bu5hm4n wrote:

I am meanwhile quite confused when it comes to sizing in this widget, what should we now do, rely *always* on parent model sizes if they are provided, and if not, try to figure out the item sizes ?

Yes, that's the idea

The problem with this stragety is, that in cases where we do not yet have the item ready, we do not know the size, and there we need some sort of size for it. And if we rely on the item sizes, then there is no parent, so also no parent size. So i do not know if this stragety works for us.

I don't think that's an issue? Just create a single dummy item when the model is set if there's no sizing info and cache its size internally.

The top 2 patches in https://git.enlightenment.org/core/efl.git/log/?h=devs/zmike/cv resolve this entirely.

@cedric have you pulled in these patches ?

@cedric ?

In a sense yes.