2013/2/5 Tom Hacohen <tom.haco...@samsung.com>
> On 05/02/13 09:50, Davide Andreoli wrote:
>
>> Hi,
>> I'm reposting this as I don't get any reply...maybe Tom missed it ;)
>>
>
> I did miss your previous mail, good you've reposted it.
>
>
>>
>>
>> After some more Eo tests I have this example:
>>
>>
>> void my_win_del(void *data, Evas_Object *obj, void *event_info)
>> {
>> elm_exit();
>> }
>>
>> EAPI_MAIN int
>> elm_main(int argc, char **argv)
>> {
>> Evas_Object *win, *r;
>>
>> win = eo_add_custom(ELM_OBJ_WIN_**CLASS, NULL,
>> elm_obj_win_constructor("main"**, ELM_WIN_BASIC));
>> // eo_unref(win);
>>
>> elm_win_title_set(win, "Elementary Tests");
>> evas_object_smart_callback_**add(win, "delete,request", my_win_del,
>> NULL);
>> evas_object_resize(win, 320, 320);
>> evas_object_show(win);
>>
>> r = eo_add(EVAS_OBJ_RECTANGLE_**CLASS, evas_object_evas_get(win));
>> // eo_unref(r);
>> evas_object_resize(r, 100, 100);
>> evas_object_show(r);
>>
>> eo_del(r);
>>
>> elm_run();
>> elm_shutdown();
>>
>> return 0;
>> }
>> ELM_MAIN()
>>
>
> No, spank. eo_del means your delete the object, you don't want that.
> It should be:
No, that line was there to simulate the user that want to really delete the
rect.
spank rejected :)
>
> void my_win_del(void *data, Evas_Object *obj, void *event_info)
> {
> elm_exit();
> }
>
>
> EAPI_MAIN int
> elm_main(int argc, char **argv)
> {
> Evas_Object *win, *r;
>
>
> win = eo_add_custom(ELM_OBJ_WIN_**CLASS, NULL,
> elm_obj_win_constructor("main"**, ELM_WIN_BASIC));
>
>
> elm_win_title_set(win, "Elementary Tests");
> evas_object_smart_callback_**add(win, "delete,request", my_win_del,
> NULL);
> evas_object_resize(win, 320, 320);
> evas_object_show(win);
>
>
> r = eo_add(EVAS_OBJ_RECTANGLE_**CLASS, win);
> evas_object_resize(r, 100, 100);
> evas_object_show(r);
> eo_unref(r);
> r = NULL; // optional but recommended.
>
>
> elm_run();
>
>
> eo_unref(win);
> elm_shutdown();
>
>
> return 0;
> }
> ELM_MAIN()
>
> Or at pastebin:
> http://pastebin.com/5ktWadGE
>
> Please take a look at the changes to the:
> r = eo_add(EVAS_OBJ_RECTANGLE_**CLASS, win);
> line.
>
yes, you are right, my fault here. Parent must be the win not the canvas
(as it was with
the old api)
> It's just ref counting, ref when you hold a reference, unref when you are
> done with it. The parent holds a ref to it's children, so you can unref
> once you don't really need the reference, you do eo_del in order to unref
> and detach from the parent (i.e, killing the object)
Ok, what was not clear to me is the fact that eo_add() create an implicit
ref.
So If I want my object to be deleted with his parent I need to unref (also
If I didn't
call an explicit eo_ref). Instead If I want the object to be deleted on
user request I need
to NOT call unref, so that eo_del() will work without warnings.
But I want the rect to be deleted when the parent is deleted AND ALSO when
the user
directly ask for it :/ how can this be done?
>
>
>>
>> Problems:
>> - with the 2 eo_unref() calls commented out the app freeze (without any
>> warnings) on
>> elm_shutdown(). Probably because not all objs has been deleted.
>> - with the 2 eo_unref() calls DEcommented the shutdown is ok but then the
>> oe_del(r) is
>> causing the warning:
>> ERR<9335>:eo lib/eo/eo.c:1306 _eo_unref() Object 0x1452fe0 already
>> deleted.
>> ERR<9335>:eo lib/eo/eo.c:1306 _eo_unref() Object 0x1452fe0 already
>> deleted.
>>
>> Thoughts:
>> - doing the unref() just after the eo_add() does not have any sense to me.
>>
>
> The only reasoning you should apply to using unref is: do I want the ref?
> The parent refs the child anyway, so if you don't need the ref, you need to
> unref (after you really stopped manipulating the object!).
>
> - deleting the win using eo_del() seems not to delete the child objs
>>
>
> It does, as long as you unref your references to them, otherwise, they are
> retained as long as you keep your refs. That's how ref-counting works.
>
>
> - forcing the user to delete ALL the created object before the shutdown is
>> an hard
>> requirement; can work with simple examples but not in real life
>> applications.
>>
>
> It's not deleting, it's just a matter of controlling your refs. It's like
> claiming asking a user to call free on every allocation is an hard
> requirement.
>
>
> - using the new api or the old one cause different behavior :/
>>
>
> No it does not. APIs were added that behave differently than the old APIs
> and they behave differently, if they would have behaved the same, there
> would have been no point in creating the new API.
>
so, yes, they behave differently :P
In the end I'm coming to the conclusion that using Eo to make the python
binding is
NOT a good choice, as it will make the usage more complex (because the user
is forced
to understand and use the ref/unref magik).
Please prove that I'm wrong...
DaveMDS
>
> --
> Tom.
>
>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
