Edje got a new program action called PARAM_COPY in the form:
action: PARAM_COPY "src_part" "src_param" "dst_part" "dst_param";
This will copy the parameter "src_param" from part "src_part" to
parameter "dst_param" of part "dst_part".
So far so good, why the "crazy" in the first line? Because this also:
* do type conversion!
* set properties of native parts, not just EXTERNAL!
The type conversion allows one to get an integer and display that in a
text property, or get an string and convert into a float.
The set of native parts is quite simple, basically a map of Edje.h
edje_object_part_*_set(). With that one can set the string to be used
by a TEXT, or set drag page/step/size/value! (page/step increments are
not supported at the moment, if it is worth, they may be supported in
future).
Sample EDC:
{{{
// test.edc, compile with edje_cc and run with edje_player
externals {
external: "elm";
}
collections {
group { name: "main";
parts {
part { name: "bg"; type: RECT;
description { state: "default" 0.0;
color: 255 255 255 255;
}
}
part { name: "entry"; type: EXTERNAL;
source: "elm/scrolled_entry";
description { state: "default" 0.0;
rel2.relative: 1.0 0.5;
}
}
part { name: "display"; type: TEXT;
description { state: "default" 0.0;
color: 0 128 0 255;
rel1.relative: 0.0 0.5;
text { font: "Sans"; size: 16; }
}
}
programs {
program {
signal: "changed";
source: "entry";
action: PARAM_COPY "entry" "text" "display" "text";
}
}
}
}
}
}}}
SVN revision: 47500
You can try it by passing --enable-fixed-point to the configure. It
will produce an ABI/API compatible Edje library that use internally
Eina_F32p32 instead of double. It will load Eina_F32p32 instead of
double from eet file (thanks to eet ability to convert them on the
fly), so edje file are compatible between fixed point and floating
point version.
This patch touch almost all internal calc of Edje, I did test it with
elementary_test, enlightenment and all my test apps, but it could
certainly break some of your preferred Edje file. If you see any
unexpected behaviour please report them to me as soon as possible.
Note: For devs, I put few macros in edje_private.h that should now
be used when doing calc in Edje, please use them so that Fixed Point
doesn't break in the futur.
SVN revision: 44323
Since we are on a freeze, the patch goes on updated to current svn, but without changing its API. After the freeze some things will be added, and some will change :)
SVN revision: 43302
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
:)... this allows e etc. to adapt to massivelyt different dpi screens with
slickness that even svg can't get to... why? you scale just what NEEDS
scaling (text, button sizes, and other limiting elements). other bits like
borders, padding etc. can remain pixel-perfect and thus the look is amazing.
pixel-perfect drawing with scalable adapting.
SVN revision: 35895
having an almost parallel codepath for script_only objects - they dont get to
use the older edje api calls for part defined objects. they will have a new
set of calls specifically for them. it's partly done - very little available
now, but will expand. lots of fixme's.
SVN revision: 34699
* remove printfs that clutter output
* add efreet file type check - only parse regular files
* chekc mmap returns correctly for MAP_FAILED results
* edje has some stubs for adding script-only objecvts - but nothing useful
right now
SVN revision: 34689
Parts can choose to ignore Events with certain flags in event_flags. The default value is
to accept all events. The syntax for this is specifying in the part:
ignore_flags: ON_HOLD;
I've tried to update Edje_Edit bits also.
SVN revision: 34170
Evas now support objects that do not grab mouse down event (NOGRAB) aside
with the default (AUTOGRAB). API is meant to be extensible.
SVN revision: 30950
These can be used to automatically swallow in another group from the same file.
Parts within child groups can be referred to by a ':' separated 'full path' of
part names. Any API functions that take a part name will now accept a full path
also.
Signals emitted by child objects will be repeated up to the parents with the
source changed to be the path relative to the receiving object. E.g in the
example below, a mouse moving over the lower light green rectangle would result
in the parent object recieving a "mouse,move" signal with source "bot:inner".
**** NEW RESTRICTION **** part names should no longer include a ':' character.
This is not yet enforced by edje_cc, but will cause the part to be inaccessible
from the API.
Example EDC:
collections {
group {
name: "parent";
parts {
part {
name: "top";
type: GROUP;
source: "child";
description {
state: "default" 0.0;
rel2.relative: 1 0.5;
}
}
part {
name: "bot";
type: GROUP;
source: "child";
description {
state: "default" 0.0;
rel1.relative: 0 0.5;
}
}
}
}
group {
name: "child";
parts {
part {
name: "base";
type: RECT;
description {
state: "default" 0.0;
color: 160 208 8 255;
}
}
part {
name: "inner";
type: RECT;
description {
state: "default" 0.0;
rel1.offset: 10 10;
rel2.offset: -11 -11;
color: 210 228 76 255;
}
}
}
}
}
SVN revision: 30087
used (inside a part description) as follows:
Horizontal from left to right filling entire part:
gradient {
spectrum: "black_to_white";
rel1 {
relative: 0 0.5;
offset: 0 0;
}
rel2 {
relative: 1 0.5;
offset: -1 0;
}
}
Diagonal from top left to bottom right:
gradient {
spectrum: "black_to_white";
rel1 {
relative: 0 0;
offset: 0 0;
}
rel2 {
relative: 1 1;
offset: -1 -1;
}
}
If either rel1 or rel2 is present in the gradient block of a linear gradient, these will override any angle/origin/size specified in the fill block ('spread' is still honored).
SVN revision: 24975
Cedric BAIL
Gustavo Sverzut Barbieri
Carsten Haitzler
Tiago Rezende Campos Falcao
Iván Briano
Vincent Torri
Hanspeter Portner
Viktor Kojouharov
doursse
Caio Marcelo de Oliveira Filho
rephorm
Christopher Michael
codewarrior