Yeah... yeah... we are on a freeze and we aren't supposed to be doing things like this, but it's not change anything other than allow edje_edit to know about scripts in order to not screw them up when modifying a file.
SVN revision: 55088
Fonts should be the same as Edje_Font_Directory_Entry as it's
serialized using the same eet descriptor, so the fields should match
their order.
SVN revision: 54835
WARNING ! WARNING ! WARNING ! WARNING !
Old file format is not readable by edje directly. If you have old edje
file that you want to convert, use edje_convert. Their is no way back.
Recompile your file as soon as possible. Please report any issue you
spot as this is a huge and needed change.
SVN revision: 50936
internal representation.
The objectiv is to simplify code, consume less CPU and memory
without loosing feature. Please report any breakage when you
see them. It will take a few weeks before we change the file
layout, during that time the load time may increase.
SVN revision: 49922
will be created. The logic is the following:
* if the environment variable TMPDIR is set, use its value
* if it is not set, take the directory passed with the
-td option (see edje_cc help)
* otherwise on Windows use a temporary dir and on other
platform, use /tmp
SVN revision: 41978
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.edjhttp://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 ;-)
SVN revision: 41802
For example:
field: FLAG_A FLAG_B FLAG_C; // at least one flag is needed
And we can assign a bit for each FLAG_*, the result would be the OR between all of them.
Refactored a bit of parse_enum to re-use code there.
SVN revision: 34168
use as follows:
group {
name: "primary_name";
alias: "another_name";
alias: "one_more_name";
}
then you can refer to the group by any of these names.
SVN revision: 26546
edje_cc (and edje_recc) now support:
-no-lossy Do NOT allow images to be lossy
-no-comp Do NOT allow images to be lossless compression
-no-raw Do NOT allow images to be zero compression
-min-quality VAL Do NOT allow lossy images with quality > VAL (0-100)
-max-quality VAL Do NOT allow lossy images with quality < VAL (0-100)
this lest you forcibly make a theme .eet that is full quality with NO
compression of images, or just lossless compression (recommended for
distribution as an "original" .eet) and then make lossy only ones with min
and max quality levels.... so u can make small small small themes by just
giving up quality :)
SVN revision: 11489
files (.edc's, fonts and images) and it will even make a handy build/sh to
rebuild the .edc into the original .eet again! :)
NB: only works on .et's created with this edje_cc or newer as i needed to
incpude some extra debug info :)
SVN revision: 11431
them, include them int eh edje.eet and edje can run them. all i have to do
now is actually give the small scripts an api worht talking about
SVN revision: 9514
fixem's have been fixed. text parts work fully now, ALONG with all their
respective effect modes, fits, alignments and "chopping". a few more api
calls have been added and cleaned up. you'll need to update eet too for this
to work.
SVN revision: 7113
properly formed test.eet output file including inlined images, data structs
and all. it can display verbose output infomration if you use the -v flag.
the only problem now is that no sample .edc files are shipped. I'll make one
or 2 better ones and include them.
SVN revision: 7033
parts and what they are relative to/use. the lookups are put off until just
before write-out. order of parts still is the stacking order though.
SVN revision: 7020
Carsten Haitzler
Iván Briano
Gustavo Sverzut Barbieri
Cedric BAIL
Vincent Torri
Hanspeter Portner
doursse
Caio Marcelo de Oliveira Filho
tilman
rephorm
sebastid
tsauerbeck
rbdpngn