Now that my last lot of Lua work has been a run away success (works for me, still dunno if anyone else uses it), it's time for me to move to the next big Lua project of mine. Actually, the second next one, but they are related.
What I would like to add to edje Lua is the ability for the host application to provide new functions for the Lua script to be able to call. Also, for the host app to be able to directly call Lua script provided functions (like the current move, resize, signal. etc). Yes we have signals and messages for communicating with the host app, but sometimes a direct function call makes much more sense. We are actually half way there. Anticipating that there would be way more edje and evas stuff to add to the edje Lua API in the future, I created generic wrapper functions to make that easier. Implementing this would mean exposing those static functions, and writing more of these generic wrapper stuff. Lua already provides a mechanism for this sort of thing, but we currently sandbox that out. We can provide a very limited version of the package module, that only lets the Lua script load modules that the host app explicitly provides. This keeps edje Lua in it's strictly sandboxed state. Raster objected to this idea before, if I remember. His argument was, I think,"what if someone loads a Lua script theme that uses one of these new APIs, but they are not there?". We are gonna have that problem now, and with each subsequent release. Anyone running a theme that expects images, text, maps, and other stuff that I added to the last release, but using the edje release before, is gonna be sorely disappointed. It only had rectangles and timers. For the next release I expect to add textblock and sound support at least. Now that the edje Lua stuff is more fleshed out, it will be actually useful, I expect people to actually start using it. No one bothered before, coz rectangles are very limited. So definitely for the next release we will need a generic solution to that problem. And probably backport it to the current release. Not much harder to go from there to what I want. One use of this is to let elementary add Lua support for it's widgets. At the moment, elementary is not a dependency of edje, so this sort of thing would be the way to do that. After the big library merge, that might not be a problem. Though I for one would still prefer to be able to use edje+lua+evas without elementary on embedded projects. My next two big Lua projects are - server side and then client side Lua scripting support for Second Life (SL) style virtual worlds. This will bring the same sort of thing that WoW has to more open virtual worlds - Lua client side scripting. SL already has it's own server side scripting language, I'll be making a Lua based version of that which will need to be compatible at the function API level. Then I'll want to make a completely new client side version, but it will have to be more or less compatible at the API level with the server API. So client side Lua scripting will have to be a mixture of functions that match the server side functions, and edje Lua calls to drive the UI. Messages and signals just wont cut it for that, it will have to be functions. Coz the API functions is what existing server side scripters are used to. Before anyone argues that SL client side functions would have to send messages to server side anyway, I'll point out that some of the server side functions have purely client side results, and not just the UI related ones. These sort of functions, when implemented as client side scripting API, will not involve the server at all, just trigger existing client side functions. Simple Lua wrappers around those existing functions will work the best. Exactly in the same way that I've been adding simple Lua wrappers around edje and evas functions. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
