the parent.
When we insert object inside a smart object, they could be attached to
another layer. As long as ref counting work, nothing wrong will happen.
But during destruction of an Evas, we were just looping over all layers,
destroying each of them, without checking for refcounting. This could
cause SEGV.
This patch introduce a third loop for wiping out all layers after
destroying all Evas_Object. So no more SEGV, and no performance
regression.
Note: Do not rely on evas_object_layer_get on smart object's child, it
could give you the wrong answer.
SVN revision: 41046
The dbus api has a "flags" parameter that is now unused but may be in
future, it was missing and dbus was giving method mismatch.
I forgot to commit this but changed Ethumb_Client, then Viktor "fixed"
it by reverting such change. Now going back to my code and adding "0"
as flag.
SVN revision: 40968
and configure.ac)
* include eina_config.h explicitely in files where the macros
of eina_config.h are used
* define eina_magic_string_init() and eina_magic_string_shutdown()
even when the mugle option is set (magic disabled)
* formatting and fix in configure.ac
SVN revision: 40962
we still guess it was up and try to get its name, if not possible then
try to start it and then get is name.
another way to do it would be to always request start and just then
get its name and just then start to listen to NameOwnerChanged. But
the current way is good enough and should save some roundtrips for
good cases (server is up).
SVN revision: 40955
If there are no other main loop activity than a idlers and one idler
adds a timer, the new (and unique) timer would be ignored since it's
flagged as "just_added" and thus next iteration will not consider it,
possible entering an infinite wait as it could be the only thing to do
in main loop.
Antognolli found this nasty bug while handling timeout-and-die in
Ethumb, where the "disconnect" event is dispatched by EDBus from idler
and it was adding a timer to shutdown the daemon after a while without
clients.
By: Rafael Antognolli <antognolli@profusion.mobi>
SVN revision: 40923
ethumbd is a server waiting for requests of thumbnails via dbus. A client
library is also provided, avoiding dbus burocracy (and with an API similar
to ethumb).
SVN revision: 40899
the connection from the fork (the cserve connection). it won't catch
threads... most of the time, but i need something else for that i think.
SVN revision: 40869
The old way we could run endless with the following case:
int my_buggy_idler(void *data) {
ecore_idler_add(my_buggy_idler, NULL);
return 0;
}
since it would append to that list, then the list would never end.
Now we just dispatch up to the last know idler, then go back to
regular processing, if nothing happens we'll be back to dispatch
again.
I tested it here and works fine, but might show issues with ecore
enterers/exiters of some applications that rely on the old (broken)
behavior.
SVN revision: 40847
Cedric BAIL
Carsten Haitzler
Gustavo Sverzut Barbieri
Lars Munch
Vincent Torri
Viktor Kojouharov
Rafael Antognolli
Andreas Volz
Iván Briano