[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] evas object event callback API
On Sat, 19 Aug 2006 19:32:06 +0200 Jan Rychter <email@example.com> babbled:
> [the delay is because I wanted to have working code before I comment
> further, and work intervened]
> Carsten Haitzler:
> > On Sat, 05 Aug 2006 12:45:39 +0200 Jan Rychter <firstname.lastname@example.org> babbled:
> > In ecore_evas - you do have a problem as it expects ONE callabck only per
> > ecore_evas canvas wrapper and events
> I maintain a table of callbacks anyway and register only one dispatching
> function (that in turn calls the real callback functions), so ecore_evas
> only knows about one callback: the dispatching function. I delete that
> callback when the last callback in my table gets deleted. It's simple
> enough: about 30 lines of code to deal with all ecore_evas callbacks.
cool- thought to me i don't like this because of inconsistency - but anyway :)
> > - 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.
> Right. The *data pointer is a very neat and smart idea. I was just
> hoping I wouldn't have to allocate/deallocate structures and use the
> pointer just so that I can stick the event type in there. I really
> expected the event type to be part of the callback signature, after all
> you need it to decode the event info.
yeah. in the world of c - the data pointer is your ultimate "1 thing does it
all" friend and CAN do everything here - but you may need to allocate the data
pointer per callback set. generally though this data pointer is used to point
to some higher level object construct (eg the callback is on an object that is
part of a window or a widget etc. etc.)
> > 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" :)
> Well, I still believe that the event type should be passed to the
> callback function, but yes, I can work around it. I have to define 9
> functions, one per event structure (plus one for all the NULL event
> pointer cases). One could argue that I have to decode all these event
> structures anyway, so I might as well do it in separate functions. It
> makes my code larger, but if you really don't want to change the APIs,
> it's fair enough. The code I've written now works.
> I guess it isn't a question of "possible", but a question of
> "elegant". Fundametally, everything is possible.
yeah - but here the problem would be breaking the api in a way that breaks a
LOT of code that would need changing, and for a very "dubious" reason - the
code being broken won't be improved in this case. :( often things like this are
a matter of weighing up the needs vs the impact and making a call - and in this
case i think i make the call of "don't break the api" :(
> BTW, I was wrong about deleting callbacks, please disregard this part. I
> looked into evas_object_event_callback_del again and it does take the
> event type into account when deleting callbacks.
> > > 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.
> > >
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) email@example.com
Tokyo, Japan (東京 日本)