NOTE: for an unknow reason I always get the wrong number
of threads when doing the computation from the thread.
Even if I use volatile and mutex. So to avoid that move
that stuff in the main loop. It increase the complexity
of the code, but at least it work.
SVN revision: 60767
Now they can be set even if the list is empty (sorry discomfitor,
removing your optimization and making it O(n) again, back from O(0)).
Also notice that due to the already existing check, if a prepare
callback was already set to a fd handler, it can't be changed, so I
added that to the docs.
SVN revision: 60765
Also remove references to examples that don't exist anymore.
More examples are going to be explained, and removing them from Ecore.h
will improve the readability of that file. This is the same that was
done to Elementary.
I'm going to move all the examples reference to this file, and should
have them being pointed by functions that use them too.
SVN revision: 60598
It exemplifies the difference between ecore_time_get(), ecore_time_unix_get()
and ecore_loop_time_get(). A description of this example is also provided.
SVN revision: 60557
Subject: [E-devel] [PATCH] Add Ecore_IMF API to set the attirbute of
input panel
For supporting virtual keyboard, I'd like to add
ecore_imf_context_input_panel_enabled_set/get APIs. The detail description of
each API is included in the patch file as doxygen format.
If input panel is in 'enabled' status, the immodule will request to
show the input panel automatically When the input widget such as entry is
clicked or has focus. In some case, application programmers want to control
the input panel manually (not automatically), so I implement this API.
SVN revision: 60504
Subject: [E-devel] XRender engine causes ecore build failure
while building ecore. The problem is that this engine was removed from evas
but not yet completely from ecore. I was on IRC with Vincent Torri (vtorri)
and Daniel Juyung Seo (SeoZ) and the consensus was to remove the code for the
XRender engines, both the Xlib and XCB versions.
There is a switch over the different engine types, where there are still a few
places left where XRender is handled, grep for "xrender" or "XRENDER" and you
will find them. The question is whether to just return NULL in order to signal
that this engine is not supported or to remove the whole thing. The latter
could break binary compatibility, therefore I left those stubs in.
SVN revision: 60502
to have it in %{release} also. So let's just tag the package as ours
and try to make sure it doesn't interfere with vendor releases.
SVN revision: 60407
+ecore_con_ssl_client_upgrade
+ECORE_CON_EVENT_SERVER_UPGRADE
+ECORE_CON_EVENT_CLIENT_UPGRADE
new functions for upgrading an existing plaintext connection to SSL/TLS, as seen in STARTTLS and my nightmares
SVN revision: 60359
Carsten Haitzler
Jonas M. Gastal
Christopher Michael
Rafael Antognolli
Cedric BAIL
Iván Briano
Mike Blumenkrantz
Jihoon Kim
Ulrich Eckhardt
Vincent Torri
Mike McCormack
Hannes Janetzek
Michael Jennings
Daniel Juyung Seo
Boris Faure