Page MenuHomePhabricator

efl.ui.item
Closed, ResolvedPublic

Description

|abstract Efl.Ui.Item @beta
|├ (P) index
|├ (P) container
|├ (P) item_parent

Related Objects

StatusAssignedTask
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedbu5hm4n
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedNone
OpenNone
ResolvedNone
ResolvedNone
ResolvedNone
OpenNone
bu5hm4n created this task.May 3 2019, 12:08 PM
bu5hm4n triaged this task as TODO priority.
bu5hm4n added a parent task: T7906: efl.ui.list_item.

@SanghyeonLee Can you verify that all usages of the Efl.Ui.Item class do only require a numeric index as parent, never something like an object ?

SanghyeonLee added a comment.EditedJun 17 2019, 3:52 AM

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 ...

@SanghyeonLee @cedric @zmike @segfaultxavi How about this:

  • 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.

Diffusion closed subtask T7562: efl.input.interface as Resolved.

Most of the problems above have been adjusted. With the latest stack of revisions, this object seems to be quite clear.

A lost point that was raised by @segfaultxavi, why is it a abstract class? We should be able to make it a regular one ?

segfaultxavi added a comment.EditedJul 29 2019, 2:00 AM

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...

OK, that work is pending in D8830... you could have saved me some trouble by adding that diff to this task :)

Sorry, i should have added refs in every commit

bu5hm4n moved this task from Backlog to Trivial on the efl: api board.Aug 20 2019, 11:45 PM
bu5hm4n closed this task as a duplicate of T8155: Efl.Ui.Item.
bu5hm4n reopened this task as Open.
bu5hm4n merged a task: T8155: Efl.Ui.Item.
bu5hm4n updated the task description. (Show Details)Aug 20 2019, 11:49 PM
bu5hm4n moved this task from Trivial to Evaluating on the efl: api board.Aug 20 2019, 11:54 PM
zmike added a comment.Aug 29 2019, 7:47 AM

This seems done?

bu5hm4n moved this task from Evaluating to Stabilized on the efl: api board.Aug 29 2019, 8:55 AM
zmike closed subtask T7578: efl.ui.view as Resolved.Sep 26 2019, 8:12 AM