On Fri, 13 Jun 2008 04:35:25 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> > >> 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. :) > 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. > > 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... > > > > ____________________________________________________________ > Click here for free info on Graduate Degrees. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNPP3WVdwrDaCTwCrWkMrqEsYWm9Ah77XstAYoyoW8VVvJm/ > > ------------------------------------------------------------------------- > 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 > -- ------------- 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
