On Fri, Jan 6, 2012 at 1:46 PM, Cedric BAIL <[email protected]> wrote:
> On Fri, Jan 6, 2012 at 4:23 PM, Gustavo Sverzut Barbieri
> <[email protected]> wrote:
>> On Fri, Jan 6, 2012 at 12:49 PM, Cedric BAIL <[email protected]> wrote:
>>> On Fri, Jan 6, 2012 at 3:34 PM, Gustavo Sverzut Barbieri
>>> <[email protected]> wrote:
>>>> On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang <[email protected]> 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.
>
> I don't remember why, but we have version info in eet to, and they are
> painfull.
>
> From an application perspective, it make it impossible to be backward
> compatible. But that's the only think I can think of right now.
And how are you helping this? This just makes *LIB* authors lazier. To
keep things without breaking:
- memory to be used must be >= current, so every time memory should
increase size of class.
- existing members must be preserved at the binary/concept level.
While you can easily rename stuff (human/compiler interface, not
runtime), you cannot change the types (if callback, parameters or
return).
- you cannot reorder the members
If that is true, with the "allocation" you want, you just get the size
to be bigger, so library can surely access:
cls->new_member_app_does_not_know_about
Without worrying. If using the version size you'd have to do:
if (cls->vesion >= VERSION_APP_DOES_NOT_KNOW_ABOUT)
cls->new_member_app_does_not_know_about
And they work as well!
The second approach is more correct, as zero/NULL/false not
necessarily is ignored by the library and may affect the behavior, so
you would need to check it anyway in those cases.
The first case is said to be more reliable as you allocated the memory
and know what you access is true (sizeof() is guaranteed to be the
same). But really, if we expose the macro you avoid these mistakes...
unless the mistake is at library side (changed structure size without
increasing version -- BAD BAD BAD BUG) or the user is cheating, user
bug, he did on purpose and screw him.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
