----- "Jose Gonzalez" <[EMAIL PROTECTED]> ha scritto: > Carsten wrote: > > > Damn you Toma! damn you all to hell! :) You're forcing my hand. Stop > offending > > me with pushing edje and the script in there to do games! aaaargh! > evil > > bugger! :):):) (you're an aussie so you'll grasp the tone). > > > > Anyway... since you force me, I have made a start of what i call > "script only > > edje objects". what are these you ask? > > > > well - right now the structure of an edje object is static - in that > you > > declare it, stacking, the states objects can be in, their parameters > etc. and > > then declare "programs" that react to signals that modify the state > of this > > static structure. you can't create or destroy on the fly. you only > have what you > > have been given as declared in the .edc file. them most you have is > custom > > states. > > > > BTW - Dave. You are going to kill me for this as script only objects > are not > > editable. they are driven 100% by script - i.e. - code. you can't > have a gui > > editor. at best you can have an "ide" with auto-formatting, > tab-completion and > > hilighting... but back to the matter at hand. > > > > this has been on the "will add to edje eventually" category. this > would put > > edje directly at the level of Flash (actionscript) - just with > different drawing > > primitives (fewer vectors...). > > > > so what is it? well you declare an edje object only by script. you > define a set > > of callbacks. much like there is already the message() object, you > can delcare > > init, shutdown, resize, etc. etc. callbacks - all of which are > called when > > things happen to the object. the idea is that the script in these > callbacks > > handles creation of sub-objects as needed, on resize re-calculates > their > > geometry and moves/resizes accordingly. it's 100% driven by "code" > (script) and > > algorithms, not declaration. now you may say "but we now lose some > of the > > simplicity of a simple declaration of geometry". not so. i don't > plan on > > removing this - the code should also be able to load other edje > objects > > (groups/collections) from the same file as sub-objects - or > eventually from a > > system object resource i think it's time we started to add to edje > the idea of > > calling on a system resource like "load the standard button object > here - > > whatever it is, load the standard progressbar object here, load the > system > > 'teachometer' object here etc." and have standard interfaces to > them. a user > > and system config would define where to find this and edje just > implement > > it.but - the main point is that the script objects can harness > layout objects > > within them for simplification, and vice-versa. > > > > script objects should also handle key events, all mouse events, be > able to > > create and destroy sub-objects (be they simple rectangles, images, > text or > > textblock objects or whole edje objects loaded from the same file or > a system > > fallback resource object). they should be able to use timers, > animators and even > > have lots of helper functions taking care of more complex paths and > math (eg in > > code define a path with control points then bind an object to it and > then say > > "go - follow this path for 1.0 seconds" and helper c code handles > moving the > > object along its path with an animator). my main interest is to make > this stuff > > available to the designer so they can design anything they like > inside a data > > file - abstract the core logic of code more from the ui and let the > ui do > > things like handle layout, interaction, animation, etc. etc. > > > > right now edje does not have all this power - it has a small > smattering of it. > > the idea is to bring it in full-force. at least all the core basics > to start > > with, and then expand the power. it's not all that hard to do. i > have actually > > laid a lot of the groundwork in cvs already. what it mostly needs is > more api > > calls - and due to it being a little different needs different > bindings for the > > calls and code paths - how they are run. the old script pushed and > popped a new > > vm instance often - per call. script only objects push it once and > maintain 1 > > vm object that exists in a running state per edje object. the cost > is higher > > than a non script-object, so use only when you really need/want to, > but with > > greater cost comes greater power. i am thinking that using the > existing message > > passing and signal interface of edje can act as a communications > pipe. as can > > swallowing of objects, setting text parts (all of these would be > callbacks to > > the script object). so you'd have more callbacks that can get called > to handle > > when the program wants to set a label's text or swallow a child > etc. > > > > what do you guys think? as i said - all the nuts and bolts are > there, just need > > to add a load of calls to export to the script. i have a few done > now - just > > enough to test with a script-only object that has a few hundred > > sub-rectangles... it works. :) > > > > commentsies? > > > > 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?
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 > > > ____________________________________________________________ > Click here to save cash and find low rates on auto loans. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3ndyH3CfkpNo7YzaHFKj0mBoqZKp8OqbUt5Rygsy1fMKohXG/ > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
