Yes.

We should be able to review it next week as work on Collection_View has uncovered a lot of shortcoming.

Let me finish my work on Efl.Ui.Collection_View and I will provide patches for stabilizing Efl.Ui.Property_Bind and Efl.Ui.Factory_Bind. They are in good shape as @SanghyeonLee is pointing out.

@stefan_schmidt you do love voting! We should organize some live vote during EFL dev days ;-)

Yes, @segfaultxavi this is indeed what the boolean model. Thanks!

In T8184#142195, @tasn wrote:

Also, the more I think about it, the more it seems like an efl_part API like described above could maybe be the solution to all of this, and in bindings have obj->text_comp->text_set().

I would think that overexposing API from a class and have it automatically propagated everywhere would not be your favored choice for internal object. It seems to me more logical to carefully choose which API is exposed and only expose those out as they then require to be forever supported (Made the mistake to use composite on elementary combobox and overexpose to many API unknowingly, so I am very cautious of the argument of automatic propagation for composite object). Also extending the interface supported by a class should not break API of that said class and its inheriting class.

I will let you land the patch, but don't forget to update the commit message appropriately.

Looks good and make me wonder if catching events handler through callback is a good strategy.

I feel like this code would be simpler if instead we were to use an Eina_File along efl_file_mmap_set. Wouldn't that always work without the need to do the if case at all?

Oh,I see. I need to look more at the code from a computer. Ping me next week on this.

I don't think it make sense as you really only want to pass value and promise do not have value only future will have. When a user get an eina value, it is usually to read a value. A promise is the writing end of a value, so a user won't be able to read a value and it might be very weird to use that way. The current API really make the eina value only the reading end aka a future from a promise, the rest is internal cooking.

I am not sure how an iterator can be async, but I may be misunderstanding what you have in mind. As for index, I was thinking iterator<int> for the interface where the int is the index of a selected element.

As long as you only expect index as information on your iterator, that would work to some extent (basically the user can not override the selection model and expect it to work without complying to this interface, which I think is a ok constraint).

You could check the structure packing, last time I did was maybe 10 years ago and as things grow organically, there might be some win there.

In D9820#182526, @SanghyeonLee wrote:

only worries are composite_model private header,

Yes, going with a simpler version should help. I was planning to run an idler for removing things from the cache with some time constraint to not completely clog the main loop during a cleanup cycle, but all of that can be done later.

I think it makes sense anyway as their will be always case where you might want to do some call after construction. Just take note that the caching factory will need to do that call too when it gets its object out of the cache, I would think.

I agree!

We could delay fetching value from model to until we set the theme, but before we do any calculation,I would think.

In D9536#180914, @ali.alzyod wrote:

@cedric what is your meson/ninja args do you use for building ?