On Tue, Jan 10, 2012 at 12:03 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Fri, Jan 6, 2012 at 5:14 PM, Gustavo Sverzut Barbieri
> <barbi...@profusion.mobi> wrote:
>> On Fri, Jan 6, 2012 at 1:46 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
>>> On Fri, Jan 6, 2012 at 4:23 PM, Gustavo Sverzut Barbieri
>>> <barbi...@profusion.mobi> wrote:
>>>> 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.
>>>
>>> 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
>
> Agreed on every thing.
>
>> 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.
>
> I now remember why ! If you allocate the structure yourself, you can
> set all pointer to NULL. So when you are rebuilding an application, if
> they don't touch the code and you added new functions pointers, they
> will be zeroed. The version would have told you that the size of
> structure is fine, but not that the user didn't properly initialize
> it. This is why I prefer this solution, it's more robust over time. It
> help us prevent API and ABI break. That's a must.
zzz... read what I've said, I've mentioned this and why this is not good.
--
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
