Having Efl.Ui.Factory.create be synchronous is not powerful enough for all our use case. We need it to become asynchronous. Proposed prototype would be to simply return a future<Efl.Gfx.Entity>. Need to adjust current view to work with it.
- Differential Revisions
- D7423: eo: fix efl_future_then example.
D7393: ecore: add a full test for efl_future_then and efl_future_chain.
D7392: ecore: fix typo in comments.
D7391: ecore: add efl_app_test to the meson build and run the test.
D7390: ecore: efl_app_suite doesn't need to depends on Efl_Net.
D7381: ecore: use efl_future_then to simplify the code logic and reduce potential bugs.
D7380: ecore: remove unecessary intermediate variable.
D7379: eo: make efl_future_then have a data pointer in addition of the object pointer.
D7332: elementary: make Efl.Ui.Factory.create asynchronous.
|Open||None||T7142 efl 2.0 considerations|
|Open||cedric||T5301 Make EFL easier to use by improving its interface|
|Open||felipealmeida||T5354 Provide infrastructure for MVVM|
|Open||felipealmeida||T5333 Cleanup View interface aka finish MVVM|
|Resolved||cedric||T7472 Asynchronous create function in Efl.Ui.Factory|
I think it should still be a function. future<Efl.Gfx.Entity> efl.factory.create(...) replacing the current create function. As the factory is the one building widgets, it has to do it at the right time. And the factory is also the only one that know what data are mandatory to create a widget and which one can wait for later.
Making the create function work for multiple items at a time will make it harder to implement I think. The factory will have to get property on a list/array of model in parallel and wait for all of them to resolve. Then it will create the object and return them as an array of object. I don't think there is much gain to try to pack this at this point. Maybe later when we start to have more important work load we can start to look at where we do spend our time and reduce the calls that create problem.