note that one can turn per module debug, for example:
EINA_LOG_LEVEL=4 EINA_LOG_LEVELS=eina_stringshare:0 ./bla
will enable level 4 (debug) for all modules except eina_stringshare
that is forced to 0 (just critical messages).
SVN revision: 42224
All these individual init functions are getting messy, some modules
lack them and it's easy to get inconsistent. Safety check needs error
and log, but these need safety checks as well, some modules (lalloc,
rbtree and others) use safety checks but provide no _init().
I want to know if we really gain something to init individual
modules. It should not be that expensive as init should not allocate
heavy resources and the recommendation is to call eina_init() so most
users will do that anyway.
If people agree I'll unmark all *_init() as EAPI and make them private
to eina lib.
SVN revision: 42214
Automatically add \n to messages. Since we use that prefix, there is
no use to allow messages without \n, it would look a mess.
Some logging systems may not require the trailing newline, for example
logging to xml or syslog, for those you don't need to ignore this char
if present.
Yes, this breaks convention, but better now than latter. And the
results are not so bad.
SVN revision: 42200
eina_log_threads_enable() and then get thread safe logging with
non-main threads being printed with special notation to easily spot
those.
SVN revision: 42199
EINA_SAFETY_CHECKS will call eina_log, so calling these from inside
eina_log_print() may lead to recursion, that is really bad (although
it seems it would never lead to infinite recursion).
handle d->deleted, also showing error.
SVN revision: 42198
* stderr logger was doing prefix properly but user message to stdout, fixed.
* log is improved:
* grep-able, it shows the 3 letter level name as prefix, unknown levels
will have their number printed.
* colors just on prefix, less polluted output still easy to spot.
* function names are highlighted.
SVN revision: 42197
* more docs.
* do not getenv("EINA_LOG_ABORT") everytime, just at init.
* EINA_UNLIKELY() in some critical paths (not that big impact anyway)
* eina_log_print_cb_stderr() and use it by default.
SVN revision: 42196
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
* eina_error might be kept for error messages and codes, but it's logging API
will be deprecated. For now, it's been kept for not breaking others code and
for a smoother transition.
* Added test for new logging API, also demonstrates usage.
SVN revision: 41960
files according to the doc
* define _GNU_SOURCE before the inclusion of alloca
as features.h inclued by alloca.h, defines some
macros according to _GNU_SOURCE.
SVN revision: 41940
Subject: [E-devel] [evas] Add RGBA -> grayscale 64 entries palette conversion
This is needed for E-Ink devices outta there. Names of new files,
configure.ac variables and macros are awful, suggestions are welcome.
SVN revision: 41825
Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols
was not updated, so there is no point to look at the actual minimal
versions of symbols.
SVN revision: 41824
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
Kubo just found that docs could be improved and macro could be
simplified during his learning of EFL. Big bonus he did the
improvements =)
SVN revision: 41799
- 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
- Forgot to reset clip before drawing cleanup rect.
- Always draw a rect to reset the background, just
choose a correct color.
Note: This will slow down software_x11 engine, as this engine
always do memset, so it does it twice. Before only the alpha
case was impacted, now both case are. Need time to fix it. If
someone has, don't hesitate :-) You can use elementary windows
state test, to see if thing is going correctly or not.
For the record, SDL engine has a score around 500 under X11 on
my computer, where the X11 engine does only have a score around
450.
SVN revision: 41770
Note: It's not a good idea to initialize curl, if you just
want to do some ecore_con network or ipc. Better let them
initialize separatly.
SVN revision: 41743
- Provide two functions with a better name (Still need more doc).
- Deprecating old eet_data_descriptor*_new.
- Provide helper function for eet when using eina data type.
SVN revision: 41732
<dieb_> weird, undefined refernce to eina_cpu_count
<raster> you have no cpus!
<dieb_> dammit!
<Sachiel> try eina_hamster_count
<dieb_> lo
<raster> oh god
<raster> now u did it
<raster> i have to add that
<dieb_> heheheh
SVN revision: 41727
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
Vincent Torri
Carsten Haitzler
Gustavo Sverzut Barbieri
Massimo Maiurana
Christopher Michael
Iván Briano
Daniel Kolesa
Cedric BAIL
dieb
Lars Munch
Davide Andreoli
Mikhail Gusarov
Hanspeter Portner
Rafael Antognolli