> > Until a more generic solution presents itself, why not have
> > a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has
> > a function to get an underlying evas..?
>
> Getting to the evas is not a problem:
>
> embed = ewl_embed_widget_find(some_widget_on_my_evas);
> evas = embed->canvas; /* Should probably write a _get for this as
> we have a _set */
>
> The problem comes down to the event dispatching, since EWL marshals
> it's own events (for a variety of reasons). We would still need a way
> to feed event dispatching into Evas for a sub-tree of the objects on
> the Evas.
Umm... It still sems to me like you'd want some kind of canvas
widget to which one could add arbitrary evas objects to, directly or
indirectly (I believe that etk has something like that), in order to
have a more flexible "evas objs in a ewl app" system, and just feed ewl
events on that canvas widget to the underlying evas..?
But as far as the particular events issue you bring up, maybe
you could write up a preliminary evas patch with the changes/additions
you feel are needed.. and battle it out with raster if need be. :)
_____________________________________________________________
Click to get information on how to convert your home equity into cash with a
reverse mortgage.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mI5r1fcZsC2CxSOZLFsNLviDuKojDR5z76gSgJXAG11o3gs/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
