On Sun, 16 Aug 2009 00:02:30 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
don't yay too fast. it has a fair few bugs to be worked out. :) > YAY! I can't believe, but it finally happened! =) > > On Sat, Aug 15, 2009 at 11:33 PM, Carsten Haitzler<ras...@rasterman.com> > wrote: > > On Wed, 12 Aug 2009 07:31:06 -0700 "Hanspeter Portner" > > <vento...@airpost.net> said: > > > > ok. werd. > > > > 1. thanks mucho mucho mucho. > > 2. stick around. i've had to fix the patch to match some changes cedric did > > of late to the custom struct. it works.. mostly now. > > 3. i am seeing a few segv's and visual bugs (eg in showcase.edj - the arrow > > group doesnt draw until i move/resize it first). > > 4. on shutdown i am seeing "Edje Lua memory limit... reached". in fact the > > ela->cur is going below 0 to negative. there's double-frees somewhere. > > 5. this seems harmless right now as its isolated in the lua script and > > sections of code - so that's good - runtime isolation of new things is > > awesome. > > 6. i'm putting this in svn now - so it can be worked on. it's not ready for > > prime-time imho - some of the test.edj's fail: > > Lua runtime error: [string "edje_lua_script"]:410: attempt to perform > > arithmetic on field 'radius' (a nil value) > > for example. i need to look into in detail some of these, but i don't have > > time just now, but will find the time. i'll have questions, and any help you > > have in tracking these down will be good! > > > > again. AWESOME work. much more than i expected. you have proved an > > exception to my pessimism of assuming nothing would ever get done. you went > > off and DID it! i love being proven wrong in these cases! :) awesome work > > mate! but as i said. it needs work. and now that can begin. > > > > i encourage everyone to try this out - get the .edj's mentioned: > > > > http://didgmo.sourceforge.net/showcase.edj > > http://didgmo.sourceforge.net/test.edj > > > > edje_decc them for src and try them out with your favorite edje tool (i was > > using the old venerable edje test app in TEST/orig/edje - i did modernise > > it to compile locally). anyone wanting to start hunting crashes or the > > negative mem alloc values, lua bitches etc. - go for it! the more people > > debugging it - the better. > > > >> This concerns Ticket #109: Add Lua support for Edje > >> > >> It adds Lua as scripting facility to Edje, letting Embryo untouched. > >> It should be easier to use and be more flexible than Embryo, imho ;-) > >> > >> --- > >> The patch > >> --- > >> > >> Lua 5.1 is used in sandboxed mode. Lua byte code is not > >> platform/architecture independent, Lua code is saved as text in the Edje > >> container and parsed at load time, therefore. > >> > >> The patch goes in two directions > >> > >> 1) Analogous to Embryo for scripting logic, messaging and custom states. > >> The same things are implemented as in Embryo: > >> > >> - messaging from and to C > >> - manual creation of timers, animators, pollers for custom events / > >> animations > >> - manual manipulation of Edje parts by means of the public > >> edje_object_part_* and internal functions and custom states > >> > >> -> those routines are actually implemented as Lua bindings to > >> functions in Edje.h and Ecore.h > >> -> the implementation is done in an object oriented way, so that the > >> interface gives the feel of an object description language, pretty > >> similar to EDC itself > >> -> combining custom states and custom animators allows for fancy > >> animations and transitions, e.g circular/spline translations or > >> complex/conditional transitions, etc. > >> -> this is just the same as Embryo does, but implemented in Lua, so > >> nothing new here, actually > >> > >> 2) Dynamic object creation and manipulation > >> > >> - this interface stems from the 'script_only' objects in Edje. Those > >> objects are a kind of scriptable Edje counterparts to Evas_Smart > >> objects. The infrastructure for Embryo is already there, but has > >> never been used > >> - I added this in Lua and added some first bindings to experiment > >> with > >> - I thought it would be useful to allow for a limited dynamic > >> creation of ui parts > >> - We can create instances of groups from within the same Edje > >> container and use them just like the main Edje object as stated in > >> 1) > >> - And there are some stand-alone bindings to dynamically create > >> Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples > >> > >> -> this may be useful to decouple the program from the ui even more, > >> to be able to do things that have to be done in the program itself > >> atm, but actually belong to the user interface, but need dynamic > >> creation of objects or complex interactions > >> -> those objects are manipulated manually with Lua bindings to the > >> corresponding edje_object_* and evas_object_* functions > >> > >> --- > >> Discussion points > >> --- > >> > >> Both stuff in 1) & 2) is functioning, but needs testing, feedback, > >> improvements, ... > >> > >> Stuff in 1) can already fully replace Embryo scripting with Lua > >> scripting. There still is space for improvements/additions, though. > >> > >> Of the stuff in 2), I think it may only make sense to add the dynamic > >> creation of groups defined in the same Edje container. Dynamic creation > >> of other Evas_Objects makes not much sense, as most of them can already > >> be used as Edje parts and be manipulated with custom states (apart from > >> polygons and lines) and it would make the whole theming potentially more > >> programing-like and much more susceptible for errors, etc. > >> > >> Would this be useful, or drop it all? > >> > >> The scripting should be there just for logic, conditionals, custom > >> states and animations, not for a whole dynamic canvas, imho. > >> > >> There is a patch around with EXTERNAL Edje parts. Seems to be a better, > >> faster, more secure way to extend Edje with custom objects. > >> > >> There would be the possibility of precompiling Lua code at compile time > >> (edje_cc) for faster loading, but we would have to patch and run our own > >> Lua version. > >> The Lua parser is pretty fast, though, and using > >> byte-converted/endianness-swapped byte-code does only pay off for Lua > >> chunks of some kilo lines. > >> Byte code also occupies much more space than text in the final Edje > >> container, as it includes debug symbols. > >> > >> --- > >> > >> Cedric and Vincent told me, that the plan was to replace Embryo totally > >> by Lua before the official release of Edje at the end of the year? So it > >> would make sense to bring Lua to svn soon and look how it fits in, test, > >> debug, adapt it further to the themers needs, decide on its final shape, > >> GATHER SOME PEOPLE TO HELP ;-) > >> > >> --- > >> > >> The Lua enhanced Edje is in sync with svn and can be get directly here > >> git clone git://repo.or.cz/edje_lua.git > >> cd edje_lua > >> git checkout -b lua_patch origin/lua_patch > >> > >> or apply the attached patch > >> > >> There are also some examples to show the usage of the things mentioned > >> above > >> - showcase.edj: shows usage of custom animators, custom states, > >> messaging and the script_only object > >> - test.edj: test cases of script usage and bindings (custom states, > >> custom transitions, tween_states, animators, timers, object_parts), > >> but most of it are experimental script_only objects > >> > >> http://didgmo.sourceforge.net/showcase.edj > >> http://didgmo.sourceforge.net/test.edj > >> > >> The source of showcase.edc is attached, too, to just have a glimpse at > >> Lua inside of EDC > >> > >> --- > >> > >> So, what do you guys think? > >> > >> Thanks and sry for the looong mail, hehe ;-) > >> Hanspeter > >> -- > >> Hanspeter Portner > >> vento...@airpost.net > >> > >> -- > >> http://www.fastmail.fm - A no graphics, no pop-ups email service > >> > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus > > on what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
