On Thu, Nov 23, 2017 at 10:42 PM, Carsten Haitzler <[email protected]> wrote: [...] >> - broadcast events: use Eo as below: >> >> * no "event type", just event object (which as its Efl_Class, of course); > > that was the idea. you allocate a new event type (get an int or handle). you > then GET the event type object from the loop, then listen to "event" callback > on it. same one on every event type object. the object "represents" the event > type. since events can be posted multiple times and are not one-off, futures > don't really apply.
they do since they provide an easy way to chain and to keep order. But okay, shall you prefer to optimize for "recurring" instead of single-shot, that can be done with an internal data structure change. I'd sill provide single shot callbacks for convenience. but more important and not mentioned here: types should be just "Efl_Class". that's it, no register/query etc. [...] >> * efl_loop_receiver_add(loop, Efl_Class event_class, cb, data); // >> or better name to "add broadcast receiver, like event cb" >> * efl_loop_receiver_del(loop, Efl_Class event_class, cb, data); // >> or better name to "del broadcast receiver, like event cb" >> * efl_loop_broadcast(loop, event_object); >> > > close to what i was thinking. i was more thinking: > > // called once ever in an application: > Efl_Loop_Event_Type efl_loop_event_type_new(Eo *loop, MY_EVENT_INFO_CLASS); > // called to get the object representing that event type for that loop > Eo *efl_loop_event_get(Eo *loop, Efl_Loop_Event_Type type); this is legacy, thinking backwards because you had that before. You don't need that, just use Efl_Class.. that's it. no need to "type_new", no need to "event_get". Use *any* Efl_Class, then: - cb_add/del: operate on a hash Efl_Class -> list of cb - broadcast: find Efl_Class in the hash, walk the list of cb > // to listen to an event: > event_type_obj = efl_loop_event_get(loop, event_type_id); > efl_event_callback_add(event_type_obj, EFL_LOOP_EVENT_TRIGGERED, mycall, > data); > > // to post an event: > Eo *event_obj = my_event_info_event_new(event_type_obj); you don't need this, this is all handled by Eo. Just create *any* object, post it to be broadcasted. > efl_event_type_post(event_type_obj, event_obj); this is ok. > every event type want you to create a class to represent it (they all must > inherit a base event type class). the event type object is a factory that > produces event objects (this means it also can act as a cache for them via del > intercepts for example). the factory produces event objects of some specific > type based on the class you define. you can fill in the obj with appropriate > data at creation time, then when ready, post the event to the loop by the > standard "post" method that is in the event type class. since the event type > object knows what loop it belongs to, it will post to its owning loop. some > time later as this queue is processed, the triggered event callback will be > called per object in the queue. I think this is not required. It's okay to require the object to be a subclass of a given type, but other than that, it should be created as usual, by efl_add(), parent is the loop, etc... >> Then internally: >> >> >> // efl_loop_receive_once() >> loop->receivers[event_class]: hash class -> array of promises to resolve. >> promise = eina_promise_new(...); >> future = efl_future_then(loop, eina_future_new(promise)); // use >> efl variant to auto-delete future if loop dies! >> loop->receivers[event_class].append(promise); >> return future; > > i dislike this for reasons above. the promises are really the domain of the > "action" to create and handle. the event queue is just s pub/sub bus. > one-off's > are what jobs are for. we already have efl_loop_job's for just this and they > are promises/futures. they need some deferring/event queue mechanism to live > on > top of. they currently depend on the legacy ecore jobs which depend on > the legacy event queue. that is the thing i need to replace. i consider jobs > (one-off events) a solved problem other than replacing the use of of the > legacy > ecore event and job api's inside the code. :) I get that, but I believe that handling the one-off is simpler, then you just re-add. Shall you want to go the complex route, okay... the structure changes a little bit, but not much. Create the recurring loop->receivers[event_class] as a list of cbs (changes "promises" by recurring cbs). Then for the "promise/future" (one-off) helpers, you auto "del_cb" after the promise resolves. >> I'd not go with Eina_Value as events. It could be done, would work >> exactly the same but offers less flexibility (needs copy intead of ref >> count, no way to protect members). But if Eo is considered too heavy >> or cumbersome, it could be used. (cumbersome: remember eolian should >> help!) >> >> For Eina_Value_Type, special care would be needed for structures... >> I'm not expecting users to create new Eina_Value_Type for each event, >> rather just use EINA_VALUE_TYPE_STRUCT or similar. In these cases, >> "subtype" is needed, that describes the structure itself (it can be >> used as event_class). Or impose it's always a structure and in this >> case pass the Eina_Value_Struct_Desc instead of Eina_Value_Type as >> "event_class". > > eina value might be another option for the event object to be posted, but i > kind of leaned to the heavier eo objects... because i know it's what we do for > input events already and it can be optimized as above to be less costly. yes. They can be refcounted... and they can protect their setters... so better for this approach. go with eo -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
