On Thu, 29 Mar 2018 13:17:43 -0400 Cedric Bail <ced...@ddlm.me> said:
> 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. it'd be good to stop doing that... :) long term at least. the slow and steady steps are to fix our parenting in efl and examples. :) i fixed it for you - or well i fixed everything i saw you changed. it may not be perfect, but it's a step in the right direction imho :) point out if i got something wrong. i didn't do "Extensive" work like you say and convert to EFL_MAIN or within efl modify code to pass parents around many levels down or something. > > > > 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 ! no problems. i was holding that commit until i heard back from you. done. :) -- ------------- 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
