> -------- Original Message -------- > Subject: Re: [E-devel] ecore / efl loop work > Local Time: December 20, 2017 5:30 PM > UTC Time: December 21, 2017 1:30 AM > From: ras...@rasterman.com > To: Andrew Williams <a...@andywilliams.me> > Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> > > On Wed, 20 Dec 2017 18:36:30 +0000 Andrew Williams a...@andywilliams.me said: > >> Since this came in the core_loop example is no longer working correctly. >> https://git.enlightenment.org/tools/examples.git/tree/reference/c/core/src/core_event.c >> There are a few ERR about timers being dead and objects having parents that >> didn't happen before. >> Additionally a EFL_LOOP child of mainloop is created and a timer attached. >> The timer no longer gets the TIMER_EVENT_TICK callback. >> Any hints as to where I should start looking to see what is broken? >> >> woooo... creating a loop that is a child of another loop in the same >> thread... >> sounds totally wrong. 1 loop per thread. at least for the legacy ecore calls >> - >> they will try and work on the mainloop singleton not the extra created loop. >> you COULD do this as long as everything is either in one loop object or the >> other cleanly.
It was actually done on purpose and I fixed a few bugs related to this once in. The logic is that it does allow for having multiple application running in the same process. I was thinking of using that for embedded multi application using JS runtime. It would have provided clean enough isolation between each runtime. <snip> >> but putting a loop as a child of a loop is going to be a nasty proposition >> as a >> lot of the logic wants to walk back to the root object to find the loop. if >> it >> finds another loop along the way... what do we do? i never really looked into >> that or tested it. and indeed some objects may have parents they didn't have >> before. this seems to be a bit of a pervasive issue at some lower levels and >> in >> corners of efl that need to be ironed out before we can call our api or >> design >> stable or even close. They stop on the first loop they find and it is exactly what we are looking for as a behavior here. You create your Efl.Ui.Win by parenting it to the loop you are given. It being a subloop or something else doesn't really matter as a loop object provide you with the needed feature fir Efl.Ui.Win to work. 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
