Sometimes the items returned from the factory still have a min size of 0x0, which is related to edje not having set the correct min size yet. For now i made it fallback to the parent model size. However, After the item has its minsize and is different to 0x0, we need to tell that to the position manager, or the cache-calculated sizes are completly invalid.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T8177 Collection_View Tracking ticket | ||
| Open | None | T8197 Invalid sizes |
Comment Actions
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.
Comment Actions
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?
Comment Actions
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.
Comment Actions
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.
Comment Actions
The top 2 patches in https://git.enlightenment.org/core/efl.git/log/?h=devs/zmike/cv resolve this entirely.