Subject: [E-devel] Provide sensible errors for edje utilities
If you start edje_player or edje_inspector with a path to a file that doesn't
exist you get a bogus error message saying that the file doesn't contain any
groups. The attached patch uses access() to check if the program can read the
file, giving a sensible error message if not.
I have checked the other utilities there, too, and they work, with the
exception of edje_external_inspector. I'm not sure how this one works at all,
but it seems not to take a file but a list of modules, maybe someone with
greater insight can take a look at that.
Going through things installed under bin, I'll take a look if those behave
properly and create patches for those, too, if this one is okay.
SVN revision: 60338
Subject: [E-devel] Edje: using fdopen instead of fopen in edje_cc
On windows, using open() followed by fopen() does not work. Hence, in
edje_cc, where mkstemp (which uses open) is followed by fopen, edje_cc
fails.
Instead of fopen, we can use fdopen. I pasted a patch below. Can you
comment it (like, instead of keeping the filename in the function that
i modified, why not using it for the fd?
(changes - closefd) removed from data_write_scripts() as fclose()
handles that)
SVN revision: 60299
1. table to have min.h/v ability like box
2. to ACTUALLY implement box h/v (and well of course implement
tableh/v too)
this basically fixes this working at all and completes the feature to
table too.
SVN revision: 59960
This lets you limit the allowed sizes of the TEXT part (font sizes) to
a specific range. This is especially useful in combination with the
"fit" property.
SVN revision: 57395
Date: Wed, 23 Feb 2011 20:25:38 +0100 (CET)
On Wed, 23 Feb 2011, Mike Blumenkrantz wrote:
> vtorri! help!!!! :(
try the attached patch
Vincent
SVN revision: 57284
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
This tool inspects a binary EDJ file and dumps group names, part
names, parts, programs, externals, images, fonts and global data of
it. The output is in both human readable (edc-like) and machine
readable (easily parseable with shell scripts).
It allows filtering of groups, parts and programs names using glob
expressions (fnmatch). Also allows filtering of parts/prgrams that are
marked with "api:".
My idea is to later change elementary-generator to use this tool and
generate code for any Edje file, generating stub code for windows and
layouts marked with names "elm/win/*" and "elm/layoyt/application/*",
exposing parts marked as "api:". It would be much more helpful and
extensible than the current generator that is based on pre-defined C
code.
SVN revision: 54846
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
I needed to bump minor file format version, but it will only
change behaviour for people using alias for part and they
couldn't use the signal emitted by them.
SVN revision: 53305
* lower case domain names;
* binaries use their own color (EDJE_CC_DEFAULT_LOG_COLOR)
* log messages do not take multiple lines, it's annoying. The colors
should call your attention already.
* the ever annoying "did you forgot fixed: 1 1;" message that used to
consume 3 lines is now bit more descriptive and uses a single line.
SVN revision: 53178
Calling help in edje_player was showing the wrong order for sending a signal.
The right order is the same of the function edje_object_signal_emit()
SVN revision: 52105
It will show a warning when loading file that may use feature from
newer edje (show up with EINA_LOG_LEVEL=2 in the env).
Please don't forget to increase it when you add feature to edje
file format without breaking backward compatibility.
SVN revision: 51636
Apply badzero.cocci, badnull.coci and badnull2.cocci
This should convert all cases where there's a comparison to NULL to simpler
forms. This patch applies the following transformations:
code before patch ||code after patch
===============================================================
return a == NULL; return !a;
return a != NULL; return !!a;
func(a == NULL); func(!a);
func(a != NULL); func(!!a);
b = a == NULL; b = !a;
b = a != NULL; b = !!a;
b = a == NULL ? c : d; b = !a ? c : d;
b = a != NULL ? c : d; b = a ? c : d;
other cases:
a == NULL !a
a != NULL a
SVN revision: 51487
Store filename for the fonts when adding eith Edje_Edit. By Fidencio
Use the hash in edje_file to dump fonts with edje_decc, avoiding the
need for the fontmap, which should probably be taken out entirely later.
SVN revision: 51095
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
* Remove vim modelines:
find . -name '*.[chx]' -exec sed -i '/\/\*$/ {N;N;/ \* vim:ts/d}' \{\} \;
find . -name '*.[chx]' -exec sed -i '/\/[\*\/] *vim:/d' \{\} \;
* Remove leading blank lines:
find . -name '*.[cxh]' -exec sed -i '/./,$!d'
If you use vim, use this in your .vimrc:
set ts=8 sw=3 sts=8 expandtab cino=>5n-3f0^-2{2(0W1st0
SVN revision: 50816
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
Remaining:
edje_lua.c:328: ‘_edje_lua_reg_count’ defined but not used
edje_lua.c:409: ‘_edje_lua_rawgetfield’ defined but not used
edje_lua.c:445: ‘_edje_lua_free_metatable’ defined but not used
edje_lua.c:2182: ‘_edje_lua_object_set_pointer_mode’ defined but not used
edje_lua.c:2190: ‘_edje_lua_object_set_precise_is_inside’ defined but not used
SVN revision: 48142
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
it means that e17 can run on OpenSolaris using Sun Studio
or gcc. It actually runs if temperature and battery modules
are disabled as they don't compile yet.
Also, the problem on Mac OS X problem with C++ comments
can be fixed (I think). See FIXME in that patch
SVN revision: 44519
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
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
Ulrich Eckhardt
Vincent Torri
Boris Faure
Christopher Michael
Carsten Haitzler
Vincent Torri
Raoul HECKY
Mike Blumenkrantz
Cedric BAIL
Tom Hacohen
Iván Briano
Gustavo Sverzut Barbieri
Leandro Pereira
Lucas De Marchi
Bruno Dilly
kiwi
Tiago Rezende Campos Falcao
Viktor Kojouharov
Sebastian Dransfeld
Hanspeter Portner