I'm the one scratching the lua itch right now, and honestly no one cares. Except raster, as lua2 and script only groups were his ideas in the first place. So I want to go along with his thoughts. Would be great to have them. B-)
Others can feel free to comment to. You might actually care once lua
is fleshed out, so best to get in early.
One of rasters stated goals was to allow lua script only scripts to
access edje parts. So these are my ideas about how to do that.
For my purposes, setting text and state on edje parts is important. So
is color and text classes, but I've done them already. I'll try to
take other stuff into consideration. I'd love this stuff to get into
the next EFL release that is happening soon. That would make my life so
much easier. B-)
What we have already is a lua table called edje that contains C
functions. There is one function for creating an evas rectangle. There
are a bunch of functions for dealing with evas objects we create from
lua. There are other functions for messages, signals, timers, and
other things. My earlier patch adds color and text class stuff.
There are some things evas can't do for edje objects. Like setting the
edje state of an edje object. So we would need to check if it's pure
lua evas object, or an edje object we are pointing to.
OPTIONS:
0) function method.
edje__object = edje.get_part("group/name", "part_name");
edje_object:state("default", 0.0);
edje_object:text("some text");
text = edje_object:text();
As in embryo, it deals with the text on the part right now, not the
text in specific states.
1) table method.
ASSUMPTION:
Collections are pretty much combined I think. Groups within a
collection override previous groups with the same name. Groups from
later collections do the same. The only thing in a collection is
uniquely named groups. So we don't really need a collections table.
Instead of edje.collections["group/name"], edje.["group/name"] works
fine, so long as there are no conflicts between the group name and lua
edje functions. Lua likely that as a string key, which would be
different from a function key of the same name. I've not tested that
though when using the table.key syntax sugar, and was burned on the
whole table[0.0] nonsense.
edje["group/name"].parts.part_name.state = "state_name 0.0";
edje["group/name"].parts.part_name.state = {"state_name", 0.0};
edje["group/name"].parts.part_name["state_name 0.0"].text.text =
"some text";
text = edje["group/name"].parts.part_name["state_name 0.0"].text.text;
edje["group/name"].parts.part_name = "some text";
Unlike embryo, we can deal with the text on the part right now, or the
text in specific states.
We can also extend this to other bits of the edje -
edje["group/name"].parts.part_name
edje["group/name"].parts.alias.alias_name
edje["group/name"].data.key
edje["group/name"].script
edje["group/name"].programs.program_name
2) combining the two.
It boils down to these two being the same thing -
edje.get_part("group/name", "part_name")
edje["group/name"].parts.part_name
So, we can do these things -
edje__object = edje.get_part("group/name", "part_name")
edje_object["state_name 0.0"].text.text = "some text";
edje.get_part("group/name", "part_name"):text("some text");
edje.get_part("group/name", "part_name")["state_name 0.0"].text.text =
"some text";
edje["group/name"].parts.part_name:text("some text");
3) any other suggestions?
I like option 2. Lots of flexibility, and I don't think it will
require much more code to implement.
Notes about lua syntax:
For those not familiar with lua syntax. The only data structure in lua
is the table, an associative array, but it's very flexible. Any type
can be a key (except nil, and sometimes the number 0 or 0.0. see
below), the values in any given table can be any type. table[key] is
the usual way to access a table member. Since using strings as keys is
common, and to make things look like data structures from other
languages, table.string_key is syntactic sugar for table["string_key"] .
So here I use table["group/name"] coz it's common to have / in group
names, and group/name is a division expression resulting in a number,
not a string key that is suitable for the above mentioned syntax sugar.
But then there is the table[0.0] nonsense ...
First, in lua 0 and 0.0 are the same. There really is no integer type.
However, lua has more syntax sugar for tables with positive integer
keys greater than 0, they can be treated like odinary arrays. There are
some language features that deal with them that way. You can mix these
sorts of keys with non integer keys, the non integer keys are ignored
by those language features dealing with oldinary arrays.
The lua developers say that these arrays start at 1. In reality -
Tables with numeric keys that are equal to 0 only work sometimes.
Sometimes they are just "keys can be anything", and work fine. Other
times lua thinks "Hey, this is an integer, and you can't have an
integer key of 0 for arrays, coz arrays start at 1". Sometimes this
later case has NOTHING to do with language features that deal with
ordinary arrays.
The reason why this is important - in previous examples of this API, I
used "state.default[1.0]" coz "state.default[0.0]" or even
"state.default[0]" don't work in my test script. And since edje state
indexes are between 0.0, and 1.0, as well as the requirement for every
part to have at least a "default 0.0" state, we gotta deal with zeros
in a language that does not like them. So I added 1 to that part. sigh
Might be better off just treating them like strings, which is what I
have done this time around.
Would be better if the lua developers got off their "people don't
understand counting from zero" high horse and just let 0 be a legal
table key ALL the time, just like every other damn value.
--
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
------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
