>> Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.......................
>>
>> Ok, let's back-up a minute here and let me ask you this: Why not
>> start by first having a more or less extensive set of embryo bindings
>> to evas objects/api?
>>
>
> for this to work with edje those bindings do need to be created - but by and
> for edje. every resource created (evas object) must be tracked by edje and
> cleaned up afterwards, etc. etc. so the bindings as such would be custom to
> edje due to the need for wrapping them an tracking them by edje.
>
> so it's part and parcel of the same work.
>
This just seems like the kind of limitation that often occurs
here for some reason. :( Why should something as potentially useful
as embryo, or LUA, bindings to evas be solely available within the
context of some sort of edje system?
Sure its use in edje might want to wrap things within edje
structures of whatever sort, and keep state and so forth, thus creating
an edje extension, but why couldn't this be done via an evas binding that
was separately available? I don't know man.. you may want to think this
thru a bit more.. just because it might be easier or more expedient to
do this solely within the context of edje internals doesn't mean that
would be best for "e". Things like script language bindings to evas/ecore
are potentially useful to many - including to what could be done with edje.
____________________________________________________________
Sweepstakes!!!
Enter for your chance to WIN a summer spa getaway!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UjkSZp4WFm2yeWA8B0MrWTMXXOhlq53WvzG0ePpKKd4z0I/
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
