* 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
* ecore-ipc is an option for ecore-config and not a required dependency
* use Requires.private field in all the .pc if pkg-config 0.22 or later is
installed. We list in it the required packages needed to compile the modules.
* remove uneeded flags that are in Libs.private (those from the packages
that are listed in Requires.private)
SVN revision: 42873
that's it, it's here... tested and works fine, please try with your
favorite gmainloop dependent library and report problems. Suggestions:
* GConf to access Gnome and its applications settings.
* GtkSettings to access other properties of Gnome and its applications.
* GUPnP (okay, we have EUPnP, but they have more features so far)
* Rygel, based on GUPnP.
* Libsoup, SOAP and HTTP access, useful for web access and required
by other libraries.
* Mojito, by Moblin, access to various web2.0 services like flickr,
picasa, twitter...
And last but not least, this enables Flash plugin on WebKit-EFL and
may enable us to get Google Gadgets sooner (before someone writes a
proper EFL backend).
Support is auto-detected at compile time but can be disabled with
--disable-glib. Runtime support is not enabled by default (so
compiling with it will just link yet another library), one needs to
call ecore_main_loop_glib_integrate() to do so.
Thanks to INdT folks that provided the initial implementation. I
rewrote it to make it correct, but the idea was good.
SVN revision: 42825
Hey raster,
Here is the non intrusive patch I talked to you about. Please apply it as it
introduces some fixes, some improvements and mostly and underlying
infrastructure for future RTL improvements.
(note hebrew & yiddish seem fine, but things expedite test seems to show are
wrong (why i don't know as i dont speak the langs- just comparing to pango /
gtk output):
arabic seems lsightl wrong (maybe composition chars not working?)
gujarati - also seems wrong
malayam - also looks wrong
persian - looks wrong
sinhala - looks wrong
tamil - looks wrong
these are what, appear to me, to look wrong. why they look wrong, i don't
know. i'm guessing its compositiong not being handled. but i dont's peak,
read or write any of these languages so i am unsure of what it really should
be like, why and how to fix it.
anyone want to put up a hand? (everything else is displaying fine as best i
can tell - the langauges i read/speak/somewhat understand are working fine).
SVN revision: 42814
Note: They are saved as EET_T_DOUBLE, and you can request fixed point value
where you stored EET_T_FLOAT or EET_T_DOUBLE. In fact now any floating point
or fixed point value can be retrieved as any real number type you need. Eet
is taking care of the convertion for you.
SVN revision: 42800
In this case slc->first wasn't being set, as well as the info.col and
info.row. This could bring some strange behavior like a call to
eina_tile_grid_slicer_next() not returning false.
SVN revision: 42783
Function allocated reply->children_len bytes, and then copied
sizeof(Ecore_X_Window) * reply->childen_len bytes into the buffer, leading
to memory corruption.
SVN revision: 42624
support this (atm). there is possibly little point in doing so... perhaps
svg... thought maybe tiff too later? for now, get jpeg 100% up to snuff.
SVN revision: 42587
people were not noticing it as they were using 64 bits machines... but
with 32 bits just 4 bytes were copied and 3 were missing :-P
SVN revision: 42549
move some to error/critical, remove trailing \n.
NOT doing ChangeLog entry on purpose, it's useless as it's an
intra-release change (changes the previous unlreleased change)
SVN revision: 42547
Have all source to include config.h conditionally (HAVE_CONFIG_H),
define EINA_LOG_LEVEL_MAXIMUM, minor changes to configure.ac to make
it conform with the rest of efl.
SVN revision: 42544
Some methods are missing and the in-process thumbnail needs to be
done, the documentation is almost the same as the client, so I really
appreciate someone else do it :-)
SVN revision: 42541
be way too big to ever allocate. probably code can do with other fixes too.
also make jpeg loader rudametarily understand load regions. very brute-force.
but enough for just this moment to do testing.
SVN revision: 42507
* Callbacks were named to help Vala bindings.
* All callbacks get 'void *data' as first argument, always.
* All async methods get free_data parameters and call them also on disconnect()
* queue_remove() renamed to generate_cancel() to be more clear.
* queue_clear() renamed tp generate_cancel_call() to be more clear.
SVN revision: 42445
This new iterator receives a rectangle as argument and tile_w X tile_h sized
tile, and slices the rectangle iterating over it on each iteration.
SVN revision: 42427
We list in it the required packages needed to compile eet.
* remove uneeded flags that are in Libs.private (those from the packages
that are listed in Requires.private)
Patch by dottedmag, modified a bit.
SVN revision: 42367
Many people try "make check" and then complain they have some error
messages, but they are actually expected... but even for the
experienced is hard to know whenever it was expected or not, so
explicitly say that.
Also check if safety checks are enabled or not before doing "break"
tests, otherwise we'll end with segfaults and tests failing. (I have
not tested with them disabled, but should be okay).
SVN revision: 42360
This will concatenate all source files in the hope compiler will do a
better job. On my test with static/built in mempools it saves me 4k, I
guess some intra module calls can be saved.
SVN revision: 42315
It's pointless to be able to change magic number string after it's
created, so let's avoid walking the existing list and just remove
places where strings were being duplicated (list/array both inited
magic strings for accessor/iterators).
Also an optimization, register using an array and sort it before
searching. Sort will just happen when array was changed, and this is
just done when eina_magic_string_get() is called.
SVN revision: 42310
Being able to indivually initialize individual modules was initially
"good", but at end it's putting complexities on users that would try
to "optimize" by doing just what they used, but in the end most people
would get them wrong, users would have to do lots of code and etc. At
the end it does not worth.
Most module init just register handful errors and log domains, so are
cheap. The exception is mempool users, that would dlopen() stuff, but
people that are concerned (embedded) can just compile those statically
in eina.
Since at the end any real application would use most of modules, we
actually end saving lots of function calls that would do nothing other
than increment a global counter.
I also did the init/shutdown use an array, making it easier to
maintain. The inital dependencies were analysed by a script I wrote, I
hope it's all right.
Please fix any breakages you find!
SVN revision: 42300
Note : currently, because of a circular calls of
eina_log_init() and eina_safety_checks_init(), eina
is not correctly shut down. Imho, eina_log should not
depend on the safety checks module. That would mean
some fprintf in eina_log_domain_new(), eina_log_domain_free(),
eina_log_domain_register()and eina_log_domain_unregister().
SVN revision: 42292
with small modifications and fixing
ecore_evas_win32 does not build, though. I think that
if we add log support in evas, all the macro must have
different names, because of all the _private.h headers
that are included in all source files (that's the problem
with win32). I'll fix ecore_evas_win32 build later. Or
someone can do it if he wants :-)
SVN revision: 42274
write down specialized cases for threads or not, function or file,
color or not. Maybe it's not even an optimization since we add yet
another indirection/function call, but each case is simpler.
* EINA_LOG_FILE_DISABLE=1: disables show of file:line in
stderr/stdout messages.
* EINA_LOG_FUNCTION_DISABLE=1: disables show of function() in
stderr/stdout messages.
one must not use the two options at the same time, if that's the case
code will ignore EINA_LOG_FILE_DISABLE=1 and use just function
disable.
SVN revision: 42272
Users may opt to set EINA_LOG_LEVEL_MAXIMUM to some integer and macro
will then evaluate to check for that value before actually call
eina_log_print() macro. By using optimizations compilers will
effectivelly compile out the code if it is never reached, thus saving
the check and function call in possible critical paths.
SVN revision: 42269
remove debug_level options as it is better handled by EINA_LOG_LEVELS
and EINA_LOG_LEVEL variables, for example:
EINA_LOG_LEVEL=3 EINA_LOG_LEVELS=ethumb:4,ethumb_client=1
will show debug for ethumb (lib), just errors (no warnings) for
ethumb_client library and everything else shows "info".
SVN revision: 42261
Sparse Matrix was implemented and tested by Rafael Antognolli and
myself in order to implement optimized large sparse matrix walk in
some products, one of them WebKit-EFL optimizations.
We have done extensive tests, with good code coverage. Similar to
lists/inlists, we keep pointer to last known element and similar to
iterators we keep reference to last accessed row and cell inside
rows. This allows fast sequential access (for i... for j... m[i,j]),
that is our most common usage case.
Rows are kept in a list, with cells inside that row as another
list. It's not similar to most book implementations where cells keep
reference to their sibling cells in other rows as well, we opted to
not do that to save some pointers and make algorithms simpler, still
do great for our use case.
This code was developed on behalf of our client, that wants to remain
unnamed so far. Thanks client ;-)
SVN revision: 42243
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