On Thu, Jun 12, 2008 at 2:24 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> 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?
I like the idea. With minor additions, like gettext calls (i18n), ways to send/retrieve objects to/from edje (layouts), and helpers to get animations easily we can have a great platform. Toma and others: continue to push for it! Excellent work! ;-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------- 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
