As long as expedite test pass and everyone comments has been addressed, I think this is good to go. The thread API is not used by EFL in the hot path, so that part is not the important bit. Maintenance and fitting into the host OS is more important.

In D12151#232371, @jptiz wrote:

In D12151#232370, @cedric wrote:

This is really not ideal. A few feature will be broken when porting an EFL apps that use eio/efl_io_model/filemanager to Windows. Isn't it possible to get some of the feature of efreet to work on the platform you are working on?

I think I can see your point but it is not that clear to me how things would break. Could you give me an example just to understand?

This is really not ideal. A few feature will be broken when porting an EFL apps that use eio/efl_io_model/filemanager to Windows. Isn't it possible to get some of the feature of efreet to work on the platform you are working on?

Your benchmark seems to indicate that the new version result in more work and just the CPU clock got run at higher frequency which made it faster. Could you do your benchmark by running your CPU at full fixed speed just to be sure?

As said in a previous PR, would be nice to refactor this.

Indeed, I always hide my tab.

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.