On Fri, Jan 6, 2012 at 1:23 PM, Hyoyoung Chang <hyoyo...@gmail.com> wrote:
> On Fri, Jan 6, 2012 at 11: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.
> Well, I think it's also good approach except itc free handling.
> itc free function should not be exported users in my thought.
> because if users remove itc ref counter,
> it could cause segfault by genlist internal behaviors.
> And if itcs bind to genlist, that makes easier cleaning itcs in memory.
>
> Anyway i think it's a good solution too.
What are you doing that you want to use this?
If you are creating item classes dynamically on an application, you're
doing it wrong.
If you're doing it for a binding, take care:
1 - store the "wrapped/bound" item class methods (Python, JS...)
in the void *data;
2 - store the newly allocated Elm_Genlist_Item_Class at "void
*data" as well, methods should point to your wrapper!
3 - clean your Elm_Genlist_Item_Class as you clean "void *data".
Variations of this may exist, for instance you can create your
Elm_Genlist_Item_Class in an explicit instance at your high level
language, then you keep this high level language instance at your
"void *data" and ref/unref it using your high level language
functions. You MUST do this to avoid being garbage collected!
--
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
