Re: [E-devel] evas object event callback API

[Carsten H. (T. R. <ra...@ra...>]

On Sat, 05 Aug 2006 12:45:39 +0200 Jan Rychter <ja...@ry...> babbled:

In ecore_evas - you do have a problem as it expects ONE callabck only per
ecore_evas canvas wrapper and events - BUT for evas this is not the case. you
can attach N event callbacks to any objects for an event type. as you hve a
generic void *data pointer for all of these, you can use this to differentiate,
pass extra data for your binding (pass in an allocated struct ptr that then
contains all of the data you could/would need - even like event type). the void
*data pointer should be sufficient for all your needs - if used right. what
about this makes it not possible to bind to another language? i have bound
identical callbacks for timers for example in embryo for scripting - a timer
gets passed only 1 parameter - a void * pointer.

if your point is that you want to create the "1 callback does all" thing and
only ever bind that 1 function to everything using the event type to then
switch off internally - then you just are wanting to do things in a way evas
was not intended to work. yes - it expects a callback to be set and specialized
for at least that TYPE of event. so you will need N callbacks in the binding
api - 1 per event type you  wish to handle, and then use the void *data to
piggyback whatever extra info you need :) changing the callback api will
basically break a few hundred thousand lines of code and i'd need a reason why
the current api CANNOT do what you NEED - not just a "it doesn't work the way i
wanted to do this" :)

> Context: writing foreign language bindings to Evas
> 
> I've encountered some snags with Evas callbacks and thought I'd ask
> for advice (and possibly suggest a better API).
> 
> Overall, the problem is that Evas assumes in a number of places that
> one object event callback == exactly one C function.
> 
> When writing bindings for any dynamic language one would usually want
> to pass all events through one or two C-level callback functions, so
> as to decode and convert the event structures. But the current API
> pretty much requires that there be exactly one C function per event
> handled: event type is not passed to the callback, so the function
> called needs to be specialized in advance for that one particular
> type.
> 
> In dynamic languages there is usually no "compile" step (or it is
> optional), so there is no way of knowing ahead if time which callbacks
> will be needed. At a certain point in time the program may request a
> certain type of callback to be added. It would be good to be able to
> do it without necessarily needing to create a completely separate C
> function to handle just this one particular callback case.
> 
> The other issue is how to delete unwanted callbacks. At present
> callbacks are uniquely identified by the C function pointer. This
> makes it impossible to have one function handle several events --
> evas_object_event_callback_delete removes by comparing function
> pointers.
> 
> So, on to humble suggestions:
> 
> 1. IMHO evas object event callbacks should be uniquely identified by
> the triplet (Evas_Object, Event_Type, function_ptr). That's what you
> pass in when you call evas_object_event_callback_add, so that's what
> you should pass when deleting the callback. I'm not sure if an object
> can belong to multiple Evases, so I don't know if Evas should be used
> as well.
> 
> 2. IMHO the callback function should receive the event type as one of
> its parameters.
> 
> 3. Overall, IMHO we should not assume that one callback always equals
> one C function. I can imagine a number of cases where I'd want to have
> a dispatching function handling multiple event types or events from
> multiple objects (or even Evases).
> 
> --J.
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> enlightenment-devel mailing list
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多
Tokyo, Japan (東京 日本)