> > 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