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? -- ------------- 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
