Sometimes you want to catch an action like "clicked" from elm/button
or "mouse,clicked,1" from a regular part and want to set a property
like "play" on some object. In this case there is no source property
to copy, so setting the destination makes sense. This was possible
with Embryo, and now it is with regular "program".
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: "button"; type: EXTERNAL;
source: "elm/button";
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;
rel2.relative: 0.5 1.0;
text { font: "Sans"; size: 16; }
}
}
part { name: "entry"; type: EXTERNAL;
source: "elm/scrolled_entry";
description { state: "default" 0.0;
rel1.relative: 0.5 0.5;
params.bool: "editable" 0;
}
}
programs {
program {
signal: "clicked";
source: "button";
action: PARAM_SET "display" "text" "hello world!";
}
program {
signal: "clicked";
source: "button";
action: PARAM_SET "entry" "text" "bla!";
}
}
}
}
}
}}}
SVN revision: 47635
Choices are useful to represent enumerations and restricted set of
elements to user. Usually this is displayed in hoversel/comboboxes.
SVN revision: 47570
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
I'm now introducing a couple of goodies to make externals more useful,
they are:
* add: extra parameter with the part name. This may be used by
external objects to emit signals in the name of that part.
* param_set/param_get: set parameters at runtime, given their names
and types. This avoids requiring users to get the actual object and
call methods. This abstraction is also good because it let one uses
Elementary without even linking to it ;-) (this have limits, like
complex types are not supported). Right now this is just exposed
to C, but goal is to have it exposed in Embryo and Lua as well.
* translate: new method to translate previously strings that are
specified statically, such as the parameters names.
Four new functions got added to the Edje API:
* edje_object_part_external_object_get() so we don't have to abuse
edje_object_part_swallow_get()
* edje_object_part_external_param_set() and
edje_object_part_external_param_get() that call the external type's
functions.
* edje_external_param_type_str() to convert types to string and
provide nicer debugs :-)
TODO:
* expose external_param_set()/external_param_get() to Embryo and Lua.
SVN revision: 47456
with stringshare, we can just compare pointers instead of
strcmp. Since we'll need the stringshare later, this is a good
optimization.
SVN revision: 46925
If file changed on disc (mtime), then make the reference dangling so
it is not reused anymore on subsequent open. If it is in cache, just
free it as it is not useful anymore.
This solves the following problem:
edje_object_file_set(ed, path, group);
ecore_file_cp(new_gen_file, path);
edje_object_file_set(ed, path, group); /* still uses the old one! */
By: Bruno Dilly <bdilly@profusion.mobi>
SVN revision: 46548
* must disconnect connected callbacks, particularly those to
canvas. The object we previously connect will die anyway, but
canvas continues alive, dispatching its
EVAS_CALLBACK_CANVAS_FOCUS_IN and EVAS_CALLBACK_CANVAS_FOCUS_OUT,
causing nasty segmentation faults!
* must call _edje_clean_objects() *AFTER* the entry is shut
down. Otherwise ed->evas will be NULL and
evas_event_callback_del_full() will fail. I left extra checks on
those, since this call will return the given data (in our case
"ed") and NULL when callback connection was not found.
* flag existence of entries and if they were already initalized and
shutdown before, avoid redoing such work.
This fixes a stupid crash that bugged editje for a while now.
SVN revision: 46263
ERR() should not be used there, because _edje_lua_error() is already
an error logging function. Instead we should call eina_log_print()
directly, handling the source of the error.
SVN revision: 46058
Change group_del() to receive the name of the group to be deleted, and
change the function to not delete a group currently loaded. This causes
problems at the time of deleting the Evas_Object.
Also changed a bit the save() function and added save_all(), which saves
every group loaded, not only the one set to the object. This is mainly so
at the time of deleting a group, we can save the whole file and thus avoid
it getting out of sync with references if a group is deleted and the file
not saved afterwards.
SVN revision: 45720
More of this can be done, and some may even be too much, but I'm losing
perspective over it and either I'm inclined to move all of them or none
at all.
Reviews, comment, fixes and reverts are welcome.
SVN revision: 45115
as we are on the modules context not the array.
All the referenced projects are changed too. Remember that the list_free()
already calls the unload() on each module so no need to call list_unload()
SVN revision: 44978
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
- add preview_get() and description_get(), breaking ABI badly.
- add abi_version field to be fileld with EDJE_EXTERNAL_TYPE_ABI_VERSION
and checked with edje_external_type_abi_version_get()
SVN revision: 44135
This is the recommended way to register a batch of types, it will not
do check (hash lookup) before adding and keys are added as "direct"
(not copied), thus lighter on memory.
SVN revision: 44102
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
* change behavior of edje_shutdown() to make it more standard
* move eet_shutdown()
the order still seems strange. I don't know if i can freely move
the init/shutdown functions
SVN revision: 42958
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
- Edje_Real_Part use less memory.
- Edje_Real_Part and Edje_Real_Part_State now use a mempool.
- When both param1 and param2 are the same, only recalc param1.
- Don't compute Edje_Real_Part more than one time per edje_recalc_do.
SVN revision: 41771
if sfont=something was given to _edje_text_class_font_get(), sfont
might be untouched there and old pointer was being freed, resulting in
double free. So make sure we're using the correct pointer there.
SVN revision: 41714
Note: A bug spotted in layout of box is the reason of this revert. From
my understanding, layout require some property on the object to be
correctly set. This is done during edje_recalc_single on the part. The
layout fonction of evas would be called just after the resize. If we
didn't do an edje_recalc_do, but an edje_recalc, the call to
edje_recalc_single will be delayed and the layout property will not be
set correctly.
SVN revision: 41698
WARNING: THIS CAN CAUSE RENDERING GLITCH AND OTHER WEIRD BEHAVIOUR WITH
YOUR EDJE FILE. PLEASE REPORT ANY ALIEN STUFF.
Note: This patch cache the result of _edje_part_recalc_single, until
any relative part are moved, the object is resized or some property
are changed (like during text set or color class set).
Note: Be carefull when you call edje_object_size_min_restricted_calc,
it's really an inderect heavy user of _edje_part_recalc_single and
I wasn't able to bring it down.
Note: This patch use more RAM, around 480 bytes per Edje state, so I
don't recommand using it on a Desktop with a lot of CPU power.
SVN revision: 41663
Note: It doesn't really impact edje memory foot print yet. But in
the plan to do a computation cache inside edje, this structure
will be used a lot (I am planning to do this feature at some point,
but no ETA yet, and be reassured it will be optionnal so we can
choose between CPU load or memory load).
Note: As I was looking for similar area of improvements,
Edje_Part_Description could really use an union to reduce it's size,
but as we load this structure directly from an Eet file, we need
union in Eet first. And this should be part of a comming Edje file
format break.
SVN revision: 41652
Today signals emitted inside GROUP sub-parts are delivered to parent
group as "part-name:original-source". This is good and allow edje
groups to be reused. But no counter part to send events to inside
sub-groups existed.
This patch allows one to send a signal "signal" to inside a part
"part" that is of type GROUP by prepending signal emission with part name:
emission: "part:signal"
source: "source"
this is the same as:
o = edje_object_part_swallow_get(ed);
edje_object_signal_emit(o, "signal", "source");
but can be done all in themes, no need to go to application c/c++/python.
Based on patch by Pieter, see mail list.
SVN revision: 40489
these two new calls will escape the unescaped text if required, will
unescape when get is called.
Also I fixed edje_object_part_text_get() on non-editable TEXTBLOCK,
now it will return the text with markup.
SVN revision: 40066
Carsten Haitzler
Gustavo Sverzut Barbieri
Iván Briano
Tiago Rezende Campos Falcao
Davide Andreoli
Gustavo Lima Chaves
Cedric BAIL
Mikhail Gusarov
Christopher Michael
김지훈
Sebastian Dransfeld
Boris Faure
Vincent Torri
Jorge Luis Zapata Muga
Lars Munch
Jonathan Atton
Hannes Janetzek
Hanspeter Portner
Michael Lauer
Rafael Antognolli
Andreas Volz