>>>> I agree with Jose, the think we need is just the ability to add objects
>>>> from script... why instad do a simple function that create new parts? maybe
>>>> taken from another group in the same file, and then do some bindings to
>>>> basic evas functions like move, resize, etc. In this way you can create
>>>> objects in the editor and then manipulate the objects from the script,
>>>> don't forget we have functions to manipulate every object properties in
>>>> Edje_Edit.c
>>>>
>>>> And don't forget that the power of flash is that you can design ;)
>>>>
>>>> Your way is powerfull, but IMO is out of the scope of edje.
>>>> PS: if you want to do games in pure edje you must first find a way to store
>>>> the highscore on disk, a game can't exist without highscore :)
>>>>
>>>> Dave
>>>>
>>>>
>>> the problem is - if i do this with the current way embryo works with edje,
>>> it will be much higher overhead. every call in and out of embryo creates and
>>> destroys a vm. it retains no state. so every resize, move etc. etc is going
>>> to start to get very heavy. as i said - you can still use existing edje
>>> "design" -
>>>
>> Then maybe the current implementation needs to be redone, if possible,
>> so as not to have this kind of 'overhead'...?
>>
>
> we remove that overhead, and we replace it with another - always having to
> keep
> a vm around... :) even if the script sections are called very little.
>
> so no matter where you look you pay a price. you want to make sure you pay the
> right price for the right thing. :)
>
Seems better to have it around if there's any kind of scripting done,
than constant instances per call... but you could always use some sort of
"hasn't-been-used-in-a-while" thing as well.
>> It seems to me that a lot of what you're going to be doing here anyway
>> is to replace edje's current internal structures/states from C ones to
>> script-language ones..?
>>
>
> actually not a lot - just keep them - but they will be empty structs, and add
> in appropriate calls to the script-provided callbacks. right now the raw
> basics
> are already in cvs - i was testing. but now i want to pause and open it up for
> discussion. the script-lang would be the alternative to describing things as
> parts and geometry layout.
>
I think it's a great idea overall of course.. it's just a matter
of how to get the most of it and doing things 'right'. I definitely see
making available some kind of bindings to evas outside of edje -- and if
they are 'limited-&-secure' ones, then great.. that would be very useful
to those who want the same (I can see evolve using it), and possibly build
on top of that to 'less-secure' ones if desired as well. Some sort of
middle ground is needed here - it would be a bad idea to consolidate this
evas-scripting so that it can only be used by edje. :(
Anyway... as to the descriptive vs code separation: Most others
from html to xul to flex to wpf to ... seem to have the ability to do all
via scripting. Indeed, they can parse and write the descriptive formats
with the script language as well.
The descriptive format is used, in part, as a means to separate
code from the simpler layout/style stuff -- a kind of initial setup and/or
basic structural description of the 'thing'. They then provide script
language calls to get objs and properties from ids/names of things in
the descriptive format. This way they can manipulate objs/properties
via the script code.
I think this is a very useful feature to have, rather than rely on
script (or C) code alone.
>
>>> you might design objects that you then manipulate with script-only
>>> containers. you can load sub-objects from the same edje file and place them
>>> in the "scene". we already can manipulate what you design from script -
>>> this is a massive extension to that, and to make it simpler and easier to
>>> do, a parallel system that doesnt try and put this directly into the
>>> existing object list and layout, but instead just uses edje designed
>>> objects much like a c program does via edje's c api, would cover this case.
>>>
>>> i'm also tossing around LUA. it may be more appropriate for this kind of
>>> usage scenario...
>>>
>>>
____________________________________________________________
Summer Spa Sweepstakes
Enter for your chance to WIN a Summer Spa Vacation!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UbfVpA3L8KycATx0jmLMGH2CP1iur9ZHgHK8kcm9ooNfzO/
-------------------------------------------------------------------------
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
