in general, this should provide an improvement which scales with the amount of data being transferred:
* small transfers will incur a small amount of overhead from potentially unneeded memory as I try to account for a bug in FIONREAD which returns a number that is smaller than the actual number of bytes available for read on a socket
* large transfers will no longer require any copies of the data
on systems which do not provide the FIONREAD ioctl(), old functionality will be used
this should work on windows, though I (obviously) can't test it myself
thus ends the longest commit message I have ever written
SVN revision: 66063
ECORE-CON-SOCKS! SOCKS ON!!!!
now ecore_con supports socks (v4 and v4a only, so no ipv6) connections natively for making remote connections
for those of you who want their apps to start proxying immediately, just update and export this handy environment variable:
ECORE_CON_SOCKS_V4=[user@]PROXY_IP_ADDRESS:PROXY_PORT[:1] <--use :1 here to enable dns lookups on the proxy
SVN revision: 65934
replace \+ by + as it should be
add -E option to grep, handle the + in expression
Patch from OpenBSD via Jonathan Armani <armani@openbsd.org>
SVN revision: 65032
Subject: Re: review request : ecore x patch for X Gesture extention
Do you remember that I told you X gesture extension patch for ecore x ?
I’d like to put the attached patch to ecore_x in upstream.
This patch is just for initializing/receiving X gesture extension stuff.
Would you please put this in SVN ? : )
Thanks and regards,
Sung-Jin Park
SVN revision: 64732
EWS is a new Ecor_Evas engine that builds on top of other engines. It
will create a backing store Ecore_Evas and ecore_evas_ews_new()
windows are created in it as images, but transparent to the outside
users (similar to buffer's ecore_evas_object_image_new()).
It provides a basic windowing system, with a known background object
that can be changed to your pleasure, and issue Ecore_Events to notify
of new windows and changes like movement, etc. Then you can write a
simple window manager based on it. (See example, Elementary will
contain one as well).
Backing store is determined by your best engine (as in
ecore_evas_new()) or specified with ecore_evas_ews_engine_set() or
environment variable $ECORE_EVAS_EWS (format:
engine-name❌y:w:h:options). The size can be set with
ecore_evas_ews_setup().
SVN revision: 63848
Note: maybe it would be better to put yes in the .pc file
instead of static. I don't see any advantage having that
information in the pc file.
SVN revision: 62412
(based on patch from Boris Faure)
NB: This is untested/unsupported code. Ymmv, but using/compiling
ecore_x with versions of xcb > 0.3.6 is not supported yet (until such
time that standard distros support 0.3.8 out of the box).
SVN revision: 61971
Thread safety is disabled by default.
Enable it with --enable-thread-safety
Should cover timers, events, animators, idlers and fd handlers.
Tested with Enlightenment and elementary_test.
Signed-off-by: Mike McCormack <mj.mccormack@samsung.com>
SVN revision: 61851
near finished yet). Add working OpenGL for XCB engine.
NB: wrt Opengl...Raster, this is the env var/dlsym version you
requested this morning ;)
NB: Basically what happens is, if you know you do not ever want/use
opengl, you can export ECORE_X_NO_XLIB env variable, and ecore_x will
use pure xcb to establish it's X connection. However, if you do use
OpenGL and this env var is not exported, then ecore_x(cb) will use
XOpenDisplay to init the connection.
SVN revision: 61724
NB: IF you are going to try this, build evas with
`--enable-software-xcb` AND build ecore with `--enable-ecore-x-xcb
--disable-ecore-evas-opengl-x11`.
NB: OpenGL does NOT work with the xcb stuff yet. E itself does NOT
work with this yet either (still have to commit those changes).
SVN revision: 61385
Carsten Haitzler
Cedric BAIL
Tom Hacohen
Mike Blumenkrantz
Vincent Torri
Youness Alaoui
Sung-Jin Park
Nicolas Aguirre
Bruno Dilly
Gustavo Sverzut Barbieri
Iván Briano
Christopher Michael
Mike McCormack