Try under valgrind with --trace-children=yes and EFL_RUN_IN_TREE=1.

Except for the minor cosmetic of the .h file name not matching the function name, I am good with this. You might want to add a _unregister function as some of the register could be done in a module and disappear at any point.

In D11119#213811, @Hermet wrote:

@cedric "turnoff the ability to update theme files" What do you mean by it?

This is kind of a weird series of patch, removing LayoutFactory and then readding it. I guess it allow for less code to write. Anyway, seeing the code like this now, it looks like we can do slightly better.

rebase

rebase and expose a pointer from the accessor.

rebase

rebase

rebase

rebase

rebase

Ok, in that case, then I don't think this is a correct patch set. Is there documentation somewhere for this?

This is I think the other way around or I miss understood eo. What do we expect from accessor<structure>?

rebase

rebase

rebase

rebase and address comment

rebase

rebase and address comment

rebase and address comment

rebase and address comment

rebase and address comment

Yes, it is resolved. Twitter bug report is the future :-)

As long as you do not replace layout factory, but add a new generic factory which layout inherit from, yes.

So during the initial stage of Efl.Io.Model, it does start by listing all the files in a directory. This could then be batch notified to a composite Efl.SortedModel that would then sort them out and insert them relatively to each other and to the content of the SortedModel.

Basically that would be a batch insert at one position. This is doable, but I doubt it would be very useful.

I think that this model can have two strategy for the sorting. On the first notification of a child being added or if the count > 0 when the compositing is done, the model batch fetch all the child of the composited model and sort them using a merge sort. The idea would be to keep just an index mapping of which child of the sorted model map to which child in the composited model.

I am also not saying this is mandatory, but would be good to take this into account.

It really depends :-) For the moment, we do not have much example of Model. Efl.Io shows that in the same code, their is place for batch insertion and solo insertion. Not sure how our code base is going to look once we have some network Model and so on.

Not necessarily, it depends on the internal of the code that is doing the insertion. Very often we do have Model temporary in memory that would be near where we insert. This is especially true if we are doing sorted insertion, as this require to compare models all the way to the point where we want to insert them.

Ideally we would want the ability to insert multiple items, but that seems only possible if Model are provided and not index (As index change every time an object is inserted).

This will be necessary to provide an Efl.SortedModel.

So Efl.BooleanModel does actually provide the ability to efficiently store this information and I consider this done.

This is going to get pushed to forever, but the idea today would be to restore support for viewport inside Efl.Ui.CollectionView, then use a map or a proxy per viewport and move them around. Next step would be try to use HW acceleration as described using hardware plane and wayland ability to use subsurface.

This is actually done with an efl_provider_find done during the finalize of Efl.Ui.WidgetFactory.

I think the state of this is good enough and could be improved forever. So let settle with what we have and if anyone get time to improve in the future, we can reopen this task.

I think for long term, using legacy API in legacy object should be preferred.

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase and correct EINA_ACCESSOR_FOREACH typo.

update with the new event name