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:
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.
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)
>
>
> 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.
--
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
