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... > 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. > > 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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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
