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
* fix some event values
* Add the "Windows" key support
* manage modifiers for shift, ctrl, alt and windows keys
that support is not finished, there still several bugs.
SVN revision: 65613
A previous patch had changed its signature, but since this is an EAPI,
we can't break it. Now ecore_fb_input_device_window_set() was added to
provide the same functionality.
SVN revision: 65589
mouse is in on init (as events wont always give this) and focus
is set on show if appropriate if no focus in/out events come
from the back-end later
Fix setting override state to only hide if it should be
visible at that point in x back end support
SVN revision: 65508
Subject: [E-devel] [PATCH] add ecore_imf_context_cursor_location_set API
In this patch, it will add ecore_imf_context_cursor_location_set API in
Ecore_IMF.
The cursor location can be used to determine the position of candidate
word window in immodule.
SVN revision: 61105
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
+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
This common interface allows engines to provide whole screen
information to users.
Right now just X is implemented and it queries the size of the default
screen. I hope this is fine.
SVN revision: 59761
Mike Blumenkrantz
Carsten Haitzler
Vincent Torri
Mike McCormack
Rafael Antognolli
Nicolas Aguirre
Jiyoun Park
Youness Alaoui
Cedric BAIL
Jihoon Kim
Ulrich Eckhardt
Gustavo Sverzut Barbieri
Daniel Juyung Seo