SOCKS5 is different from SOCKS4 in that it supports password authentication mechanisms (GSSAPI is still on the todo) and IPV6, neither of which are possible with SOCKS4
NOTE THAT THE CMDLINE SYNTAX FOR AUTOSOCKSING HAS CHANGED!
* ECORE_CON_SOCKS_V4=[user@]server-port:lookup
* ECORE_CON_SOCKS_V5=[user@]server-port:lookup
also note that I did not implement autosocksing with password. it's just not safe.
SVN revision: 67959
This make it possible to completly disable signal broadcasting as this
new behaviour broke Edje 1.0 file. It's also now possible to use the
same group in different part in the same parent group without any issue.
I am tempted to backport this patch to 1.1 branch as it would make it
play nicely with file coming from Edje 1.0.
Another issue that this patch fix is that I did increment the minor version
as we really have add a lot of addition since Edje 1.1 and Edje file build
with trunk may not play well anymore on Edje 1.1.
SVN revision: 67936
array, list, struct and others set() now copies the values. These
values can be created by user, in this case string is just a stack
object and not a real eina_stringshare.
To cope with it, add the string instead of referencing it. Bit slower,
but nicer behavior.
SVN revision: 67886
Subject: [E-devel] [patch] evas - preventing retard mouse event
process in evas_object_event_callback_call
I made a small patch to prevent retard mouse event process.
At certain circumstance (like as genlist select callback + naviframe
item push),
some events are repeat processed.
If some evas_objects're iterating in evas_event_feed_mouse_up and
mouse_out event's emitted by other interrupt(such as naviframe item
push),
then some evas_objects events are multiple processed by
evas_object_event_callback_call.
More elaborating it with a example.
There are a genlist and a multibuttonentry on genlist item.
When a user clicks multibuttonentry then evas will process mouse down
and up.
in evas_event_feed_mouse_up, it gets evas object list to process mouse
events.
Then in the evas object list, there are two evas objects - rect and
textblock.
Two objects have its own parents.
the rect has below parents.
----------------------------------------
edje - genlist item
elm_genlist_pan
edje
multibuttonentry
box
entry
els_scroller (0x2a601788)
rect <== the rect
the textblock has below parents.
----------------------------------------------
edje - genlist item
elm_genlist_pan
edje
multibuttonentry
box
entry
els_scroller(0x2a601788)
edje
elm_pan
edje
textblock <== the textblock
(note : two evas object have same parent (els_scroller))
So normally mouse up callbacks event propagates to its own parent.
the rect is processed to genlist item. and the textblock is processed
to genlist item.
but when els_scroller is processed, it's blocked by checking event
type and event id checking.
Mouse Up(rect) -> Mouse Up(textblock)
event_id (3) -> event_id (3)
evas_object_event_callback_call(Evas_Object *obj, Evas_Callback_Type
type, void *event_info, int event_id)
{
...
if ((obj->delete_me) || (!obj->layer)) return;
if ((obj->last_event == event_id) &&
(obj->last_event_type == type)) return;
<=== blocked
However if naviframe item is pushed in the middle
of mouse up processing.
It can break into mouse up. So it's processed like below.
Mouse Up(rect) -> Mouse Out(rect) -> Mouse Out(textblock) -> Mouse
Up(textblock)
event_id (3) -> event_id(4) -> event_id(4)
-> event_id(3)
(note Mouse_Out is made by naviframe item push for event freezing)
If that, there's no mechanism to block that repeat processing same
event.
So I suggest this patch.
This patch blocks old events if there's no reason to process.
(It blocks old mouse_up event because mouse_out is processed.)
And I think it also clear the bug in
"[E-devel] event repetition with elm_naviframe/elm_genlist"
SVN revision: 67879
Subject: Re: [E-devel] [Patch] ecore_ipc - remove potential risk in
ecore_ipc_shutdown
I found a problem this infinite loop case.
If server is deleted, then ECORE_IPC_EVENT_SERVER_DEL callback
function will be called in client side.
It will happen infinite loop in ecore_ipc_shutdown if
ecore_ipc_shutdown called in this ECORE_IPC_EVENT_SERVER_DEL callback
function.
For example,
server_del_handler =
ecore_event_handler_add(ECORE_IPC_EVENT_SERVER_DEL, _server_del_cb, NULL);
static Eina_Bool
_server_del_cb(void *data, int type, void *event)
{
ecore_ipc_shutdown();
return EINA_TRUE;
}
If server is deleted,
1. _ecore_ipc_event_server_del : svr->event_count++
2. _server_del_cb : ecore_ipc_shutdown called
3. ecore_ipc_shutdown : while (servers) ecore_ipc_server_del(eina_list_data_get(servers))
4. ecore_ipc_server_del : can't eina_list_remove(servers, svr) because event_count != 0
5. infinite loop
I think this while code is very dangerous whether user miss or not.
I modified EINA_LIST_FOREACH_SAFE instead of EINA_LIST_FOREACH refer
to ecore_con.
Please review this patch.
SVN revision: 67874
I did a bad decision to steal memory for Array, List, Hash and Struct
types, it was nice to not have to copy it internally, but breaks when
one needs to set a new value that was set elsewhere. What did not
happen with string, integers and other basic types.
This was exposed by Raphael Kubo using eina_model_property_set() with
complex types (Array, List and Hash) and it was not possible to
correctly set such properties.
Now it's all set, but the behavior changed and the memory is not
stolen and released anymore. Test eina_test_value.c was changed to
reflect it.
SVN revision: 67843
if user get and then set the same value, we should not crash and this
may happen with previous code as the old
string/array/value/list... were released, then you ended with the
released memory still being pointed.
SVN revision: 67841
We should not flush and then setup the memory, instead we leave
vset/pset functions do their own stuff to clean previous data, if any.
SVN revision: 67840
This patch try to prevent the broadcasting of targeted message. This should minimize
the problem generated on edje sub GROUP that didn't expect to see that much message
coming to them. It just a minimization of the problem, as message that don't target
explicitly a part are still propagated and can still break your edje usage from 1.0
to 1.1 version.
SVN revision: 67830
Let's try to help debug by allowing extended reference management that
takes in account an identifier. This identifier is accounted on xref
and xunref and must match.
xrefs_get will return the list of such references, for debugging purposes.
eina_models_list_get() was added to return all live models, just
tracked when EINA_MODEL_DEBUG is enabled.
eina_models_usage_dump() was added and use the same infrastructure as
eina_models_list_get() and eina_model_xrefs_get() to aid debugging :-)
SVN revision: 67821
Gustavo Sverzut Barbieri
Cedric BAIL
Jihoon Kim
Tom Hacohen
Mike Blumenkrantz
Carsten Haitzler
Hyoyoung Chang
윤정현
ChunEon Park
Jonas M. Gastal
Rafael Fonseca
Christopher Michael