On Sat, 25 Nov 2017 20:59:08 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> 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. the event bus is for re-occurring events. That was always it's purpose. It should/would be optimized for that. If you look at the use of ecore event handlers almost every single one doesn't "register then delete itself when the first event comes in". So design for an optimize for this case, otherwise this will just be far more painful to work with having to re-subscribe inside every future. Also unlike futures there is no "else" (failure) case. This they just don't map nicely. > but more important and not mentioned here: types should be just > "Efl_Class". that's it, no register/query etc. You do need to be able to get the event object from the loop given a class at least. this is registration implicitly. I do need/want to put legacy ecore API on top somehow and so I have to be able to generate an int from this. > [...] > > >> * 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. but that is what i need. i need to replace the ecore event but as eo stuff is depending on it and its' a singleton global. > 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: Yes - I thought it over more. a @class function can do this type-safely. pass in a loop obj and class and get an event type object back: event_type_obj = efl_loop_event_type_get(loop, MY_EVENT_CLASS); efl_event_callback_add(event_type_obj, EFL_LOOP_EVENT_TRIGGERED, mycall, data); the loop will create the event_type_obj on first use and store it and after that just return the same obj to everyone who gets it. so callbacks are managed with regular eo event callbacks on the same object. > - 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... actually i think the loop should do the creating. this will ensure there is a single instance of the type object (per loop) only. > >> 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. that's more work for 99% of the use cases. forget to re add? you have a bug. something goes wrong. and that's for "99%" of the time that that bug can happen. > 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 am not even sure having one-off's are needed at all. It's so rare that people can just delete their event handler themselves in 1 line inside the cb once triggered. It's less complexity that a parallel one-off vs repeating event. jobs already are the "add a one off callback (future) AND queue the event now within the event queue timeline so it is called in order with all other queued events (after ones posted before now, and before those posted after). > >> 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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
