On 05/02/13 20:51, Davide Andreoli wrote:
>
>
> 2013/2/5 Tom Hacohen <tom.haco...@samsung.com
> <mailto: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 :)
Ah, OK. You are hereby unspanked.
>
>
> 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)
That's not a biggie, just cooler. ;)
>
> 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.
No, it's not an implicit ref. eo_add() returns a pointer to an object,
which means you will be using it, which means you get a ref. That's how
ref counting works, if you are working on it, you need a working ref, so
there's no sense in returning without a 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?
As I said, if you are manipulating an object, you should have a ref to
it. Which means everything should be fine. You might want to take a look
at weak_refs which means that you'll be able to hold a non retaining ref
to objects, and then, whenever you want ref them (to start working on
them) and then delete them using eo_del. This is just how ref-counting
works, I really can't think of a way around that.
>
>
>
>
> 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
Yes, the same way as strcpy and strncpy behave differently. Different
functions do that. :)
>
> 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...
>
Huh? It's hidden from the user using Python's automatic ref
counting/garbage collection. You should not need to do anything about
it. As I've said before, talk to Yakov about it, he had working examples
for python bindings that needed nothing of what you are talking about.
As for using Eo in the bindings: Eo is "the future" of EFL, and the old
functions will be deprecated at some point in the (far) future.
But using the legacy functions has the advantage of being compatible
with the 1.7 branch.
Do your thinking and decide.
--
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
