Page MenuHomePhabricator

Cleanup elm_index
Open, NormalPublic

Description

The cleanup of elm_index should only provide the vertical index feature (not pager like feature).

I'm checking who would be the proper person for this work.

jpeg added a comment.May 16 2017, 7:10 PM

One problem is the method "insert_sorted" which requires eina comparison functions. We should avoid using an eo function here as it could be called many many times. Ideally something like what the models use should be done. But I don't know if using a Model would be the right solution. @cedric?

cedric raised the priority of this task from TODO to Normal.Jul 10 2017, 3:10 PM
cedric added a subscriber: felipealmeida.

Hum, a model would do, but it would be quite expensive maybe for such a short list. This has to be though more. The alternative for sorting is to rely on the same trick as layout function, and ask people to inherit when they want uncommong filter case... Not sure here. Adding @felipealmeida for some additional idea.

A comparison function is where a Eolian Function would make total sense. Why not?

It also create more problem. I am repeating myself here, but the lifecycle of the context needed for a function to be automatically linked in various language is a nightmare. Possibility is to restrict it to force the context to always be an Eo object and it won't die until that function pointer is removed due to eo refcount, but then you loose the easy to use API in Eo and eo override provide you the same ability without the complexity.

felipealmeida added a comment.EditedJul 10 2017, 3:41 PM

You really are repeating yourself. But that can only be because you are not understanding the lifetime is simply fixed. And for bindings it is very easy to implement it.

A function becomes three parameters: The function pointer itself, the void* private data and another function pointer that frees the void* private data. When the method that received the function pointer no longer is going to call the function, it simply calls the function that frees the void* with the private data as parameter and then the context is freed.

The lifetime of the function is the lifetime of until it is still useful and can be called. The binding will not refcount the function pointer nor will it attach to the object that receives it. The free function is generated automatically by bindings.

How do you do eo_override for a specific parameter type? For elm_index that might not be a huge problem, because you will only use Eo objects for comparison, but that is not true for most places where sorting is needed.

The difference in syntax for languages is quite obvious too:

foo([] (auto lhs, auto rhs) { return lhs < rhs; });

vs:

struct foo_comparator : inherit< ;:efl::ui::elm_index_comparator>
{
  bool compare(object lhs, objet rhs)
  {
     X x_lhs = efl::downcast<X>(lhs);
     X x_rhs = efl::downcast<X>(rhs);
     return x_lhs < x_rhs;
  }
};

foo_comparator comparator;
foo(comparator);
jpeg added a comment.Jul 10 2017, 7:31 PM

Please keep the function pointer discussions in T5583. We understand their value and potential uses.

jpeg assigned this task to eunue.Dec 10 2017, 8:30 PM

This ticket has been mostly forgotten. I think the function pointer debate has finally been solved. We should have a new look at this. :)

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:58 AM
zmike edited projects, added efl: widgets; removed Restricted Project.Jun 11 2018, 8:16 AM