Sebastian wrote:
> > > So, should we require that evas callbacks not free their evas?
> > > (E.g. force them to schedule a free and then actually do it
> > > outside of any callbacks)
> > >
> > > Or, should we alter evas to defer evas frees while walking
> > > an object's callbacks?
> >
> > Ummm... this is really more raster's domain of intimacy :)
> > but I'd say that an evas obj's callback shouldn't free an evas
> > (wether the one it's in or any other), but the latter possibility
> > sounds like it could be reasonable as well.. I'd have to look at
> > this in more detail to give any real suggestion on my part though.
>
> It will be damn hard to prevent an evas event to kill itself.
>
Not prevent an evas event to kill itself, just not have an
obj directly execute the evas_free func in one of its callbacks while
doing a callback walk.. though I'm not sure that's what was ocurring
here at all.
Like in either one of Brian's suggestions, it would be best
to set such free requests til after all pending callbacks were done.
Alternatively, all further callbacks could be interrupted, and then
the freeing done.
Event handling is really largely dependent on the particular
semantics one wants for the timing, propagation, delegation, and
execution of requests, so it's not clear to me exactly what should
be the 'right thing' here.. wether it "works" or not.
jose.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
