On Fri, 22 Dec 2017 12:09:37 -0500 Cedric Bail <ced...@ddlm.me> said:
> -------- Original Message -------- > > > Subject: [E-devel] ecore / efl loop work > > Local Time: December 14, 2017 9:30 PM > > UTC Time: December 15, 2017 5:30 AM > > From: ras...@rasterman.com > > To: e <enlightenment-devel@lists.sourceforge.net> > > > > I've been working on this for a while and now have things in a pretty good > > state. I just pushed a commit that does a huge amount of this (not all - see > > 5dd52fd09b7d79c70b3134423a87aa6400a2d994). But it's a huge step to efl loop > > objects really being self contained. > > I didn't know where in this thread to put this email, but I have been looking > at this patch for some time and I think their is a lot that need to be fixed > now. Once all the breakage reported by Andrew are addressed, there is still > some additional design issue. The main one is the place of the equivalent of > Ecore_Event, but for the new unified API. I don't think we need it at all > actually. If you review our use of it today, it is because we have no object > for X connection for example. So we send all the message on a generic bus and > hope that they are useful for someone. With Eo, the proper design for this > case would be to have an X connection object and have event, Efl_Event, on > the object itself. If you want an Efl_Event to be delayed like Ecore_Event > was, you can just trigger the Efl_Event from the callback of an Eina_Future > and have exactly the same capability. Added benefit, you are notified when > someone does listen to your event, so you can even not prepare and send them > if nobody is listenning. > > So I am absolutely not convinced that exposing the legacy Ecore_Event API > into something in Efl.Loop is useful or should be a pattern we encourage. I > am now of the opinion that this new Event should become internal only for the > time being, until we find them a case in which it makes sense to expose them. the ecore event object isn't exposed. it's internal. efl.loop.message is exposed though as a generic message queue/bus. i assume you're talking about the latter. e uses ecore events to post events internally so multiple modules listen to it. ecore_job is dependent on such a bus. such a bus provides an ORDERED event stream where events are processed in the order posted but "a bit later on". without it efl_loop_job's just don't work. so we agree that it is needed as a tool anyway, but jobs are defined as part of an event queue processing pass. one job added before another is called before the other (in order). if something in between adding job1 and job2 produces an event... then the event is called between job1 and job2 calls. without the message bus you can't do this (post such an event in order) and a lot of efl and e and make full use of the message queue per loop. it's a pub-sub mechanism and saying "we don't need a pub-sub mechanism" is kind of odd as they are common constructs. without it you can't have events in between 2 jobs above, so it has to be exposed in order to be able to do this. for that reason alone i think it should be exposed. but either way we aren't arguing if its needed, just if it should be exposed as "public api". the efl.loop.message infra is explicitly a delayed event/messaging system as opposed to eo's "event callback" mechanism which is in-line. there is a reason i brought up the question if eo's events should be always in-line or async or able to do both. if they could do both then yes, efl.loop.message would be redundant. > 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 > -- ------------- 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
