On March 28, 2018 8:06 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Wed, 28 Mar 2018 12:37:35 -0400 Cedric Bail ced...@ddlm.me said: > > On March 27, 2018 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: > > > On Tue, 20 Mar 2018 17:57:47 -0700 Cedric BAIL cedric.b...@free.fr said: > > > at least some of these i think are wrong. > > > the benchmarks are "debatable" but ok. > > > > > > but: > > > test_bg.c > > > test_box.c > > > test_calendar.c > > > test_efl_gfx_map.c > > > test_evas_map.c > > > test_evas_mask.c > > > test_evas_snapshot.c > > > test_gfx_filters.c > > > test_glview.c > > > test_nstate.c > > > test_part_bg.c > > > test_photocam.c > > > test_part_shadow.c > > > test_ui_button.c > > > test_ui_clock.c > > > test_ui_panes.c > > > test_ui_popup.c > > > test_ui_progressbar.c > > > test_ui_scroller.c > > > ... (there's a pattern here... basically every single change for adding a > > > win) -> shouldn't it use loop as parent? > > > > This are test where we want lifetime control of this object I think. This > > just because the parent is the main loop does not mean you don't have lifetime > control. you can always del it. parent should be there to follow back to the > loop driving it for async events (futures), animator events etc. - sure. we > glue that in behind the scenes currently when there is a null parent, but > these > objects SHOULD be part of the main loop tree...
Yes, it was relying on the behind the scene magic trick to get to the main loop. > > means to me not depending on the lifetime of the main loop to get them > > destroyed, but on controlling the reference only and explicitely. This could > > be moved to use parent relationship, I have no strong opinion on this. > > as above... you still can control it explicitly. nothing ever stopped this. > it's more the problem of exposing objects that you want a parent to really > control and once exposed, the user getting the handle could violate that > contract by explicitly deleting and stealing from the parent that really owns > it - thus the part interface with the tmp objects... > > > ecore_audio_custom.c > > > ecore_audio_playback.c > > > ecore_audio_to_ogg.c > > > ecore_poller_example.c > > > efl_io_copier_example.c > > > efl_io_queue_example.c > > > efl_net_server_example.c > > > efl_net_server_simple_example.c > > > ... (more patterns... i got 25% through the diff and got bored of copy & > > > pasting samples here) > > > -> shouldn't it use loop as parent? > > > > Ideally yes, but at least for the _example, it requires to spend some more > > time to move them to use EFL_MAIN, which should be done in a different patch > > not related to fixing the usage of efl_add. > > some use EFL_MAIN ... otherwise efl_main_loop_get() will work. but moving to > efl_add_ref() isn't the "right direction" for most of these. Yeah, I haven't been a big fan of efl_main_loop_get and did tend to avoid it. I should use it more often in the future. > > > test_part_shadow.c > > > ecore_audio_to_ogg.c > > > > > > -> shouldn't is be efl_del because add should have a parent like loop? > > > > If we move them to use efl add with the loop as parent, yes, it should be, > > but as the current code use efl_add_ref, using efl_unref is the correct > > counter part. > > sure. they go along for the ride. i just saw a massive commit and lots of > changes that were not even necessary (changing to unrefs from dels and to > add_ref instead of just using a parent instead of NULL). > > ok. i've fixed it locally... i'll push. Thanks ! Cedric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
