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.
Description
Description
Details
Details
- 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.
| Status | Assigned | Task | |
|---|---|---|---|
| · · · | |||
| Open | felipealmeida | T5333 Cleanup View interface aka finish MVVM | |
| Resolved | cedric | T7472 Asynchronous create function in Efl.Ui.Factory | |
| · · · |
Comment Actions
is it event or function?
fac.create() is function which will create an class instance directly,
Create_Event will be a event which will be called when factory create an class instace.
so the T7473 and this Task talking about same thing or different one?
I little bit confusing here :)
Comment Actions
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.
Comment Actions
about D7332,
mostly view will request some bunch of items in one request,
so it would be much nice to get series of them in single event or future, but I don't know how to do this.
maybe your current patch could be thing that we can do best.
Comment Actions
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.