Page MenuHomePhabricator

Genlist Interface
Updated 895 Days AgoPublic

This document is authored for arraging and discussing genlist interface task.
anyone can be put suggest or any opinion about the task in here.
To inform the suggestor, please put the nickname in the brackets(e.g. [JadeL]).

Purpose : Genlist clean up and eo-based interface support
Due Date : 5/2, 2016

  1. Existing Problems
    • No Model based data controller : every data need to be controlled by application side. no abstract data modeling exist in genlist.
    • Performance Issues : entering the widget and scrolling, performance problem can be happen. size calcuation for each block size can cuase etering performance problem. un-obtimized style, text, content set can occur scrolling performance problem. caching user-data, object can be helpful to reduce this issues.
    • Scroll Positioning : hard to control scroll position in user side. can't expect the result by calling scroll-based APIs. (e.g. item show after appending can reflect direct scroll moves. after calcuation cycle finished, show-item will be on the screen)
    • Indexing : Index working very poor ways. index start value also looks poor. it start form 1 not 0.
    • Size Calculation : Size calcuation looks too busy and optimized-calcuation makes error in few cases (e.g. multiline changes)
    • common API usage : genlist can't use common elm_object_item APIs in most cases. style, text, content set/get APIs are not working properly and give another way-item_class based callbacks- to do this. This need to be combined one way to avoid confusing API design.
    • non EO-based callbacks : As I mentioned upon, item_class based callback is given for updating items view elements, which is not eo-based structure. we need to have not only common based APIs, also support eo-based callbacks to support legacy and eo binding properly.
  1. Gen-Family Merging
    • API Differences (not count set/get as different API)
Common API47
Genlist Only19
Gengrid Only12

full report xlsx file :

  • Can be merged : Homogeneous, Deocrate, Tree(Group), Block, Key Reordering, Wheel, Horizontal, Filter
  • Can't be merged : N/A
  • Need to be fixed : Size Set, Align, Filled, Page, Position Get
  1. Suggestion with Q&A
  • Model Based List :

[JadeL] This idea is supposed to made an pure list interface for eolian with model-view-controller concept.
Adding another abstraction on top of the current list makes poor API designs and increase userabilty confusion.
Instead of this, we can only support pure MVC-based list view model in eolian interface which covered fully on our genlist legacy widget.
the new list-view widget can set the Model(pre-builded or customized one), and Deligate.
The basic idea are suggested by felipe Magno and subhransu Mohanty.

  • Append/Prepend vs Count :

[JadeL] Most MVC list are just use index-based way, so user didn't need to append or prepend item directly,
gives count of full items, and they can control item by it's own index. current legacy genlist need to append or prepend items in applicaiton
side, so in MVC list, need to discuss which idea is better.

  • Item-based vs Index based :

[JadeL] As same as upon topic, current legacy genlist is based on item-based way, other MVC list are based on index. so if we proceed MVC list, need to discuss which idea is better for MVC list.

  • Text and Content Part :

[JadeL] Legacy genlist give text and content get callback to user, so user can know which part is exist in genlist item. but if we support common APIs in MVC list(e.g. elm_object_item_text_set), user need to type full part name of the target text, as same as other elementary widgets. how about give some eina_list for valid text and content part? for example, item->part.texts->first means the first text part string, and item->part.texts->first->next means the second one, item->part.contents->last means the last text which can valid in the item style. This idea can be extended whole elementary widget Rule.

  1. Example Codes

Here I wrote simple example codes for user cases in cpp. this example is just pseudocode, so cpp or efl grammar may not correct but it just explain what I expect to use this model and delegate in user side.

In the example code, it just create simple customized model and delegate classes, but acutally I think this customized calss won't be necessary for creating default list view. we could support very simple model and delegate for our styles and data such as array, sql, etc, so code could be more simplified in user side I guess.

version: 1.02 modified by Jade L 12, April

Last Author
Last Edited
Apr 12 2016, 3:33 AM
vitor.sousa, jpeg, felipealmeida and 4 others