|abstract Efl.Ui.Item @beta |├ (P) index |├ (P) container |├ (P) item_parent
|Resolved||bu5hm4n||T8045 How to handle longpress in efl_ui_text|
|Open||None||T7912 enum Efl.Input.Object_Pointer_Mode|
|Open||None||T7913 function Efl.Ui.Selection_Data_Ready|
|Open||None||T7914 struct Efl.Ui.Selection_Changed|
|Open||None||T7915 enum Efl.Ui.Selection_Type|
|Open||None||T7916 enum Efl.Ui.Selection_Format|
|Open||None||T7917 enum Efl.Ui.Activate|
|Resolved||None||T7919 enum Efl.Orient|
|Resolved||None||T8158 Default Item for Grid / List|
in MVVM case, as cedric pointed,
child of Efl.Model will be the invariable value for specific item,
but in view object, numeric index can be accessible.
in simple efl.ui.list/grid,
as item is packed by user, user hold the object pointer, and can access by this object pointer, or numeric index both.
is this what you required?
@SanghyeonLee Yes, thank you.
Next problem here:
This uses some internal pointer magic which needs to be set by each and ever implementation like this:
EFL_UI_ITEM_DATA_GET_OR_RETURN(it, id, EINA_FALSE); id->select_mode = &(pd->select_mode);
This is kind of a problem for C# land, since a bindings language cannot do that technically. Also, we are setting twice the same pointer in the same object:
EFL_UI_LIST_ITEM_DATA_GET_OR_RETURN(it, ld, EINA_FALSE); EFL_UI_ITEM_DATA_GET_OR_RETURN(it, id, EINA_FALSE); id->parent = obj; ld->parent = obj;
This is *again* not working for bindings, they cannot just access the internals ...
- We add a property for "container" to the item, which can be just a widget. (So we get rid of the ->parent = obj)
- We remove this internal struct from the item, and get the mutliselect mode from the container every time something gets selected.
With this we have at least the chance to have bindings working with Efl.Ui.Item.
More questions: the implementation of Efl.Ui.Item does not seem to use the Efl.Ui.Clickable mixin at all, reimplementing everything (like long presses). I can even remove the mixin from Efl.Ui.Item and everything compiles just fine.
Also, the handling of the longpress_timer smells of leaks...