We use 256 buckets with a rbtree per bucket. The key of rbtree is the hash
on 12bits and each node of the rbtree have a list of string.
Thanks to Gustavo and Vincent for their help.
SVN revision: 36000
add autogen.sh in archive distribution
* configure.ac:
remove useless defines
first support of mingw32msvc compiler
* src/lib/Evil.h:
move some macro definitions
* src/lib/Makefile.am:
add evil_(fcntl/langinfo).(c/h) and install pwd.h
* src/lib/dlfcn/dlfcn.h:
remove useless ifdef
* src/lib/evil.c:
comment all code for now. It will be deleted later
* src/lib/evil_fcntl.c:
* src/lib/evil_fcntl.h:
* src/lib/evil_langinfo.c:
* src/lib/evil_langinfo.h:
move fcntl and langinfo related code to their own files
* src/lib/evil_mman.c:
remove useless inclusion
* src/lib/evil_pwd.c:
pw var is not needed with cegcc
* src/lib/evil_stdlib.c:
fix bugs, formatting
* src/lib/evil_unistd.c:
add missing declarations and fix header files
* src/lib/evil_unistd.h:
move pid_t typedef to Evil.h
* src/lib/evil_util.c:
additional include and fix a bug in output
* src/lib/pwd.h:
use EAPI from Evil.h, define struct passwd when not using cegcc
* src/lib/sys/mman.h:
use EAPI from Evil.h
* win32/common/fnmatch.c:
* win32/common/fnmatch.h:
* win32/common/fnmatch_list_of_states.c:
* win32/vs8/evil.sln:
fix and cleanup with vc++ compilation
Based on patch by Dmitriy Mazovka
SVN revision: 35993
I did test this patch since three month in my apps and in E, and I didn't
notice anything going wrong with it. If you experience strange bug with
matching please report them.
SVN revision: 35945
them from being put in the evas_render_update phase.
I did extensively test this patch since a few month and didn't notice any
bug with it in my apps, nor in E. But please report anything that goes wrong
for you after this version.
SVN revision: 35944
One can get engine names with ecore_evas_engines_get() and present
them to its users (from --help, for example) and then give that name
to ecore_evas_new(), that accepts the name, geometry and extra options
as a string.
As I don't have all the engines here, I might have missed something
from those, tested here:
- software_x11
- xrender_x11
- opengl_x11
- directfb
- buffer
SVN revision: 35919
Edje is tricky, it's event processing is too weird and Cedric's
changes to make it work are not working as expected. Edje freezes
itself while processing signals, but in mouse down cb it forces
recalculate, which seems was previously ignored, but now they are not.
We should look at how to fix this and then re-apply this patch.
SVN revision: 35908
ProFUSION funded the rework of DirectFB engine, it works quite well,
please report problems with it and be sure to try to uncomment the
following lines to see if it helps:
evas_engine.c: (uncomment if you notice problems)
//#define DFB_USE_EVAS_IMAGE_DRAW 1
//#define DFB_USE_EVAS_RECT_DRAW 1
//#define DFB_USE_EVAS_POLYGON_DRAW 1
//#define DFB_UPDATE_INDIVIDUAL_RECTS 1
polygon.c: (comment if you notice slowdowns, but may lead to visual problems)
#define USE_SPAN_RECTS 1
You can also turn on debug by uncommenting in evas_engine.c:
//#define DFB_DEBUG_IMAGE 1
//#define DFB_DEBUG_FLAGS 1
//#define DFB_DEBUG_ACCELERATION 1
Thanks to Denis Oliver Kropp (dok) for review and patches!
SVN revision: 35904
that's about it. a bit hacky - but works and frankly.. the idea is that u'd
set a scale factor once really and not change it per obj... most likely.
SVN revision: 35896
:)... 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
You can use eet -s to sign a eet file and eet -c to check its signature. The
current code doesn't check any certificate trust path, only if the signature
match the certificate and that the certificate could be loaded. If that's not
the case, eet_open will fail. If the file is not signed, eet_open will just
continue to succeed.
SVN revision: 35882
This class covers the most common cases, usually its sub-classes will
have to implement resize and override one or two methods at most,
making the smart object usage less error prone and easier.
Default behavior is:
- add: creates a hidden clipper with "infinite" size;
- del: delete all children objects;
- move: move all objects relative relatively;
- resize: not defined;
- show: if there are children objects, show clipper;
- hide: hides clipper;
- color_set: set the color of clipper;
- clip_set: set clipper of clipper;
- clip_unset: unset the clipper of clipper;
Documentation explains an easy way to inherit from this class and
still be able to use overridden methods.
SVN revision: 35861
Some people is using it for some time now without problems, so I'm
adding it to SVN to get some broader use. Remember to recompile ALL
libraries that depend on Evas as it will change the
EVAS_SMART_CLASS_VERSION and old classes will fail to load.
This will also change Edje so it will postpone _edje_recalc() to
render time, calculate() callback, however some methods will force
early recalculation.
SVN revision: 35860
When writing jpeg scanline, it wouldn't fail with FILE* as an output, but will
with a data buffer. So we need to re run the jpeg routine on this scanline. As I
don't know if the buffer is always preserved during two calls to the jpeg
library, I am copying it again.
SVN revision: 35804
memfile.
It pass all the image test of the test suite with some little modification.
E seems to run fine with it and my apps also. But if you experience error
with eet and compressed picture, please report them to me.
SVN revision: 35795
Gustavo Sverzut Barbieri
Vincent Torri
Cedric BAIL
Davide Andreoli
Carsten Haitzler
Sebastian Dransfeld
Peter Wehrfritz
Nicholas Hughart