>>>> 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.
>
The existence of python or other bindings is its own thing..
we're talking about their use for defining edje as a functional entity.
I'm not going to get into this issue of "security" though...
if that's what you want to base the reasons why these 'bindings', generic
or not, limited or not, *have* to be solely inside edje lib internals,
that's fine with me. :)
____________________________________________________________
Want more out of life?? Fast track your career with an online degree.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNfaMcPOwjQKW7GYis7PVTahpDDMgjonDRxV8WakdT2Dpm8/
-------------------------------------------------------------------------
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
