Ok, raster said it would not happen but just crashed my machine and
e.cfg was lost due ext4 being in writeback by default. Accordingly to
Theodore Ts'o
(http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/) we
should fsync even on open-write-close+rename case.
SVN revision: 39536
**** WARNING ****
E is bugged in some place, it does swallow object from another Evas in some place.
With this patch, it will abort sooner. If you find situation where it abort, please
report. This are nasty bug hidden in our code base. And yes, you will the white box
of death, this is expected.
SVN revision: 39528
* docs: be clear if it's a copy or in-place.
* clone: add some apis to create a copy while operates, sort should
do the same.
* reversed iterator: new call to walk the list reversed, will make
life easier in some cases.
SVN revision: 39515
between all ecore graphic engine to ease porting of application and reduce the amount of
specific code per engine. This patch does just that.
All your application should continu to work has previously, if it's not the case
please report any new behaviour regarding mouse and keyboard.
SVN revision: 39505
The behavior of AC_CHECK_HEADERS is a bit strange: If one has
2 header files foo.h and bar.h and foo.h exists while bar.h
does not, then:
1) with
have headers="no"
AC_CHECK_HEADERS([foo.h bar.h], [have_headers="yes"])
the value of have_headers is "yes"
2) with
AC_CHECK_HEADERS([foo.h bar.h], [have_headers="yes"], [have_headers="no"])
the value of have_headers is "no"
SVN revision: 39479
* fix requirements
* fix configuration on mac os x (problem with automake 1.9) and
add missing values/macro for quartz support
* small typo in ecore_evas_win32 api
* use m4 api in m4 files
SVN revision: 39471
uses the same mutex macros used by the mutex on font objects, so it makes it
a bit simpler. old code is commented out for reference.
SVN revision: 39458
This should really remove unused items that would age forever in the
last, forcing old but not so to be evicted before them.
Fortunately it was not so complex to add, and should wait just 3
pointers more of space per node.
SVN revision: 39350
This cache is very simple and should work fine when system does not
change, it keeps a direct association of mime-types and found icons,
remembering theme and icon size. Search is very fast since it uses
stringshared strings and thus direct pointer comparison in hash
search. We could optimize it even more if we assumed stringshared
strings to come in, so no need to eina_stringshare_add() (which is a
hash per se), using just eina_stringshare_ref().
Cache population is limited to compile-time value and just values
older than a given threshold are deleted. I do not keep a LRU explicit
list, so you might have some old but unused items always alive. I
don't find this too bad, sure it will consume more memory, but will
not hurt performance. We can change this to purge all expired items by
not checking for number of items to remove, removing all that match.
Next I plan to find out a good way to cache and speed up file->mime
discovery. I plan to do auto-generated state-machine to match
extensions, so you don't need to check the same extension character
more than once. Example:
Input: bla.edc
Extensions: edc edj eps png bmp
It would first try to match against 'e', 'p' and 'b'. It will match
'e' and then check for 'd' (edc or edj) or 'p' (eps). It will match
'd' and then check for 'c' or 'j'. This will reduce number of
comparisons considerably.
As I'm running out of time (4am, not much time left on this month), I
could use some help here.
SVN revision: 39343