On Sun, 26 Nov 2017 10:20:26 -0200 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> On Sun, Nov 26, 2017 at 2:08 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> >> 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.
>
> hum... that works... usage would be something like?
>
> efl_event_callback_call(event_type_obj, EFL_LOOP_EVENT_TRIGGERED, data);
yes. or EFL_LOOP_EVENT_TRIGGERED i think will be a specific event per event
type (the class would define it) as this would produce typesafe callbacks in
languages like c++ etc.
i'm considering having a "not safe - requires knowing the type and using the
right methods" for c or js/lua etc. in addition to typesafe, for convenience.
this would probably have the universal "trigger" event. My idea at the moment
is to have a consistent design pattern here, just with the typed one being more
wordy in c/js/lua but safe in c++ and related langs (as typing can catch
errors).
> (that would make event dispatch synchronous), or:
>
> efl_loop_broadcast(loop, MY_EVENT_CLASS, data);
>
> which internally will queue {MY_EVENT_CLASS->data} and call
> efl_event_callback_call() at some specific main loop phase like
> before.
hmm no. i'd want to use the event_type_object handle here - place the event
object itself on the queue. looking up by class is just forcing extra overhead
in the api. using the event type object handle means the event can be queued
with the object handle of this object alongside the event object itself and
thus immediately call the right callbacks when it's processed on the queue
later on. so always "get" the event object by class first... store that
somewhere local then use that from then on (for that loop).
> I'd not oppose as it will simplify the logic a lot, basically you
> don't need to do anything at all -- all done by Eo. Including
> "walking/delete_me" logic...
but yes - internally it'd call the event_callback_call when the event on the
queue is processed "later on". the queue would just be a list of:
struct {
Eo *event_type_object;
Eo *event_object;
};
so every item in the queue knows what object to call the event callbacks on and
what to pass to this callback call (the event_object).
> then each loop contains a hash cls -> instance, return the instance
> (event_type_obj) or create and return for the first time.
i'd just avoid forcing the hash lookup every time if you can do the hash lookup
just once and store the object handle then... :)
> in that case, just be aware that MY_EVENT_CLASS for legacy is a single
> one: ECORE_EVENT_LEGACY_CLASS. It will contain "legacy_type: int"
> property, which uses the global integers to work on. Then
> ecore_event_callback_add() will connect efl_event_callback_call()
> using a proxy/wrapper, that will filter by "legacy_type", converting
> to the old dispatch system -- those globals still remain.
yup. i'd have to implement this legacy class and it'd have methods to get an
int for that object to then use the the legacy ecore event type. legacy event
types need to also support "don't call any LEGACY callbacks after this one on
the event" somehow as legacy can do this etc. etc.
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
>
--
------------- 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
