On Tue, Sep 22, 2009 at 8:03 PM, Jaime Thomas <avi.tho...@gmail.com> wrote:
> On Mon, Sep 21, 2009 at 1:20 PM, Atton Jonathan
> <jonathan.at...@gmail.com> wrote:
>> It seems like the message function in a lua script isn't called when we send
>> a message from a C program.
>>
>> lua script:
>> lua_script {
>>            function init (ed)
>>            print 'init'
>>            end
>>
>>            function message(ed, typ, id, ...)
>>                local custom
>>                print 'custom'
>>                custom = ed.shadow:custom_state ("default", 0.0)
>>                custom.rel1 = {0.3, 0.3}
>>                custom.rel2 = {0.6, 0.6}
>>                ed.shadow.state = {'custom', 0.0}
>>            end
>>        }
>>
>> embryo script:
>> script {
>>            public message(Msg_Type:type, id, ...) {
>>                custom_state(PART:"shadow", "default", 0.0);
>>                set_state_val(PART:"shadow", STATE_REL1, 0.3, 0.3);
>>                set_state_val(PART:"shadow", STATE_REL2, 0.6, 0.6);
>>                set_state(PART:"shadow", "custom", 0.0);
>>            }
>>        }
>>
>> The embryo script works well but the lua script didn't. The message "custom"
>> is never print in stdout.
>
> If you add in lua_script_only: 1; before the script it works.  I've
> attached a patch that uses the lua_State for the collection, and
> allows for message sending without script_only.  It seems to work here
> but perhaps Hanspeter could comment on its correctness.

Never mind, it allows you to call the function but not to do anything
useful inside it.

>
>>
>> 2009/8/12 Hanspeter Portner <vento...@airpost.net>
>>
>>> 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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>> --
>> Regards.
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to