On Fri, Jan 6, 2012 at 12:49 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Fri, Jan 6, 2012 at 3:34 PM, Gustavo Sverzut Barbieri
> <barbi...@profusion.mobi> wrote:
>> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang <hyoyo...@gmail.com> wrote:
>>> Dear all
>>>
>>> This patch introduces four new apis about elm_gen{list, grid} item
>>> class managements.
>>> itc_add function makes a new item_class for the given widget.
>>> And itc_del function remove the item_class from the widget.
>>>
>>> Most of elm_gen{list, grid} users declare itc(item_class) as a global
>>> variable.
>>> Because itc should be lived at elm_gen{list,grid} item's life cycle.
>>> It's inconvenient for users. Even some users pass itc.
>>>
>>> itc_add makes a new itc. if exact one exists in the given widget, it
>>> return the previous made itc.
>>> itc_del remove a itc if its reference count reaches at zero.
>>>
>>> Thanks.
>>>
>>>
>>> EAPI Elm_Genlist_Item_Class *
>>> elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
>>> Elm_Genlist_Item_Text_Get_Cb text_cb,
>>> Elm_Genlist_Item_Content_Get_Cb content_cb,
>>> Elm_Genlist_Item_State_Get_Cb state_cb,
>>> Elm_Genlist_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
>>> EAPI Elm_Gengrid_Item_Class *
>>> elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
>>> Elm_Gengrid_Item_Text_Get_Cb text_cb,
>>> Elm_Gengrid_Item_Content_Get_Cb content_cb,
>>> Elm_Gengrid_Item_State_Get_Cb state_cb,
>>> Elm_Gengrid_Item_Del_Cb del_cb);
>>> EAPI void
>>> elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
>>
>> I dislike it, one can easily do this kind of stuff using item_del_cb().
>>
>> And really, majority of developers should NEVER use this, the global
>> static-const is the correct way to go, making sure memory is live,
>> unchanged, no mallocs, etc.
>>
>> Who may use this is bindings, like Python, JavaScript and that's it.
>> They have better ways to manage it.
>
> Yes and no. The current API sucks because it's not futur proof. I
> don't like the proposal either, because it doesn't solve that issue
> either.
>
> My current idea is to have something like that :
>
> EAPI Elm_Genlist_Item_Class *elm_genlist_itc_new(void);
> EAPI void elm_genlist_itc_free(Elm_Genlist_Item_Class *itc);
>
> struct _Elm_Genlist_Item_Class
> {
> int magic;
> int refcount;
> int struc_size;
> const char *item_style;
> struct {
> ...
> } func;
> };
>
> The _new function call return a clean itc with all pointer set to
> zero. With the struct_size, the application could know if elementary
> is recent enough for him or not. The _free call just reduce the
> refcount of the itc. So it is possible to have backward and forward
> compatibility with time. Not the case with the current API. And yes,
> it would not be possible to give a static pointer once this is done.
That can be easily solved right now by introduction of version member
in the structure. The allocation has nothing to help here. Magic and
version will replicate themselves.
You can have init macros, like we have for Evas_Smart_Class.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
