Page MenuHomePhabricator

Open, TODOPublic


class Efl.Ui.Active_View.Container
├ (P) view_manager
├ (P) indicator
├ (P) active_index
├ (P) active_view_size
├ (M) push
├ (M) pop
├ (E) transition,start
├ (E) transition,end
bu5hm4n created this task.May 30 2019, 4:31 AM
bu5hm4n triaged this task as TODO priority.
bu5hm4n updated the task description. (Show Details)
bu5hm4n renamed this task from efl.ui.active_view.container to efl.ui.spotlight.container.Jul 30 2019, 11:43 PM

@Jaehyun_Cho @woohyun What do you think of changing active_index to actaully take a object and not a index ? It feels a little bit weird to me that we have to use the index here, and i am currently playing with this widget arround, and i have to use
active_index_set(obj, efl_pack_index_get(subobj)); all the time all the time ...

It is true that an integer index is only used in active_index and in the transition event data, so it should be easy to change it to use an object instead.
However, I am sure somebody will come up with an example showing that using objects is more inconvenient than indices :)

Can we add an active_object property and let the user choose whichever he prefers?

I kind of agree, but: Spotlight needs to access its internal list with nth, which costs performance, in most of the cases the user will need to get its own index, which ends in a eina_list_find call. So both times a O(n) call.
So right now:
Have a object: 2 times O(n)
Have a index : 1 time O(n) 1 time O(1)
With object:
Have a object: 2 times O(1)
Have a index : 1 time O(n) 1 time O(1)

So ... the solution with having a object is more performant.

I'm OK with that. But then we also change the indices inside the events, so everything works with objects.

Jup, good point.

Sorry about replying late.. ;)

I am OK on using object instead of indices for active_index.

Since index can be changed but object is not changed, I think that using object might be better not only performance but also from some aspects.

BTW, like @segfaultxavi 's comment, it seems that using object may require quite a bit of code modifications.

I have done the migration now in the attached revision. However, I left out the events for the reason given in the commit. We might need to fill invalid pointers to have correct values, which is weird. we do not have this issue with the index.