Page MenuHomePhabricator

efl_ui : stabilized Efl.Ui.Select_Model
Needs ReviewPublic

Authored by SanghyeonLee on Sep 26 2019, 4:53 AM.

Details

Summary

stabilized Efl.Ui.Select_Model

depends on D10190

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 13720
Build 9547: arc lint + arc unit
SanghyeonLee created this revision.Sep 26 2019, 4:53 AM
SanghyeonLee requested review of this revision.Sep 26 2019, 4:53 AM

DO NOT MERGE

it has same problem iterator<ptr(uint64)> stable error.

I don't think we need to stabilize this one as the API is exposed via collection view.

hmmm could be.
anyway we have change to make it public after released, so okay I agreed.

still it is necessary to make test case between VM and M without View at the end.

and for the notice,
me and @bu5hm4n agreed to keep multi_selectable and multi_selectable in beta,
while the selectable and single_selectale is stabilized.

are you okay with this?

@cedric can we either move this here out of review queue or dicsuss what the plan of it is ?

I think it can be out of beta as index_range is already stabilized.

SanghyeonLee added a comment.EditedDec 19 2019, 3:48 AM

@cedric
I have one question regarding all composite model.

in efl_ui_widget,
we set the viewmodel as ModelProvider class which is implements Efl.Ui.View,
but all view model including compositeModel is not ModelProvider but just implements Efl.Ui.View...
isn't it problem?
moreover... compositeModel is already out of beta so we cannot modify this...
we may can fix widget code... but then modelProvider is useless..

we set the viewmodel as ModelProvider class which is implements Efl.Ui.View,

EFL_MODEL_PROVIDER_CLASS is an EFL_UI_VIEW_CLASS and thus carry a reference to a EFL_MODEL_CLASS. It is used in the case that no model are directly set on a object, so that a batch of object can find and watch one object that will provide them with a EFL_MODEL_CLASS. This avoid having to do multiple efl_ui_view_model_set as only one call on the EFL_MODEL_PROVIDER_CLASS is needed to set the EFL_MODEL_CLASS.

but all view model including compositeModel is not ModelProvider but just implements Efl.Ui.View...
isn't it problem?

EFL_COMPOSITE_MODEL_CLASS implement EFL_LOOP_MODEL_CLASS who is itself an EFL_MODEL_CLASS. So you can set an EFL_COMPOSITE_MODEL_CLASS and any of its descendant on an EFL_MODEL_PROVIDER_CLASS.

moreover... compositeModel is already out of beta so we cannot modify this...
we may can fix widget code... but then modelProvider is useless..

We need to keep the EFL_MODEL_PROVIDER_CLASS as it is the non changing object here. You change the model on the provider only and all the widget that watch the provider get notified. Otherwise you would have to set the model on every widget that use it every time there is a change. This is just for simplifying code.