On Fri, 13 Jun 2008 03:39:36 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> > >> 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. because the evas bindings would open up doorways to security and stability holes as they would be too powerful- they would necessitate the need to create canvases and create other smart objects and move objects outside of edje's control - we'd spend a lot of work re-limiting the bindings. this is meant to be a small sandbox to play in. generic bindings are intended to be powerful and generically useful- different use cases. check how bindings are actually done first - you have to provide all the c functions to point to (and these in turn wrap up the actual evas/whatever calls). these would be different for edje as opposed to generic bindings and so there is no point worrying about the non-edje case as it is currently not useful. if you want scripting bindings python ones already exist - use them. this is a different use case and requires a different set of bindings and thus different work. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
