On Tue, Jan 10, 2012 at 11: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.
In heart, i agree with API, ABI break is definitely bad things.
But i can't get why it shouldn't be introduced.
I also think this apis looks like half-baked.
But I'm convinced genlist has mature architecture.
Current genlist archtecture, there's no possible to add more view-able
objects obtaining callbacks.
Viewable objects is only two things - text and contents.
If there's anything is added which can see, it's ground breaking
change like as from E16 to E17.
then API breaks are can't avoid.
You can't put new wine in old bottles.
And one more thing, I can justify why i choose to attach item class
api to genlist.
like some guys point out , genlist can be treated as a object.
if then genlist item also can be a object in my thought
genlist {
itcA {
icon_get();
content_get();
}
item1 {
item_class = itcA;
icon_get = itca.icon_get();
}
}
genlist->item1->item_class->icon_get();
Without any concerning without that item class is mapped with any item class,
genlist item can any parts.
In my humble opinion, i can say several advantages why it good to be merged.
1. static variable is only available in a file
2. item can be managed with the genlist lifetime. (such as allocated, freed)
3. preventing crash caused by mis-allocated item class
> --
> Cedric BAIL
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
