starting to implement xrandr 1.3 support, now we support all events
and their fields.
This commit also fix way that extensions register their ids and
base. The way it was, ids was being added to the last event id, that
was wrong! Fortunately, those that were wrong had just one event and
always added "0", making no harm.
SVN revision: 40492
ecore_events are asynchronous and can be dispatched after the server
is deleted (ecore_con_server_del()). In this case, server will flag
"delete_me" and avoid doing double-free. When the event is dispatched
and the server is deleted, we still need to free resources and so we
need to call _ecore_con_server_free(). But we cannot do that by means
of ecore_con_server_del() since it will check "delete_me" flag and
will return.
This patch calls _ecore_con_server_free() directly when events are
dispatched and server is deleted. It fixes problems with
forecasts/weather modules exhausting file descriptors, a long standing
issue that bring problems with pam/desklock authentication.
Thanks to manio to point out #305 and testing.
SVN revision: 40490
Today signals emitted inside GROUP sub-parts are delivered to parent
group as "part-name:original-source". This is good and allow edje
groups to be reused. But no counter part to send events to inside
sub-groups existed.
This patch allows one to send a signal "signal" to inside a part
"part" that is of type GROUP by prepending signal emission with part name:
emission: "part:signal"
source: "source"
this is the same as:
o = edje_object_part_swallow_get(ed);
edje_object_signal_emit(o, "signal", "source");
but can be done all in themes, no need to go to application c/c++/python.
Based on patch by Pieter, see mail list.
SVN revision: 40489
This was affecting ecore_con users, specially modules that keep
polling the network, like forecasts or weather.
patch by manio, see bug #305.
SVN revision: 40488
is it ok?
1. it can be --disabled in evas's configure, but i think it works WITHOUT
disabling it (runtime) as it falls back to the old way of loading
2. it may cause build problems on some platforms - without it being enabled
we won't find out, so enable.
3. it needs enabling runtime to make use of it so it should be safe for now
until you enable it.
what is it?
it is a SHARED cache server - that means images loaded are loaded BY the
cache server (not by the actual process using evas). images are shared via
shared memory segments (shm_open + mmap). this means only 1 copy is in all
ram at any time - no matter how many processes need it , and its only loaded
once. also if another app has already loaded the same data - and its in the
cache or active hash, then another process needing the same stuff will avoid
the loads as it will just get instant replies from the cache of "image already
there". as it runs in its own process it can also time-out images from the
cache too.
right now you enable it by doing 2 things
1. run evas_cserve (it has cmd-line options to configure cache etc.
2. export EVAS_CSERVE=1 (im the environment of apps that should use the cache
server).
it works (for me) without crashes or problems. except for the following:
1. preloading doesnt work so its disabled if cserve is enabled. thisis
because the load threads interfere withthe unix comms socket causing
problems. this need to really change and have the cserve know about/do
preload and let the select() on the evas async events fd listen for the
unsolicited reply "load done". but it's not broken - simple preloads are
syncronous and forced if cserve is enabled (at build time).
2. if cserve is killed/crashes every app using it will have a bad day. baaad
day. so dont do it. also cserve may be vulnerable to apps crashing on it - it
may also exit with sigpipe. this needs fixing.
3. if the apps load using relative paths - this will break as it doesnt
account for the CWD of the client currently. will be fixed.
4. no way to change cache config runtime (yet)
5. no way to get internal cache state (yet).
6. if cache server exist - it wont clean up the shmem file nodes in /dev/shm
- it will clean on restart (remove the old junk). this needs fixing.
if you fine other issues - let me know.
things for the future:
1. now its a separate server.. the server could do async http etc. loads too
2. as a server it could monitor history of usage of files and images and
auto-pre-load files it knows historically are loaded then whose data is
immediately accessed.
3. the same infra could be used to share font loads (freetype and/or
fontconfig data).
4. ultimately being able to share rendered font glyphs will help a lot too.
5. it could, on its own, monitor "free memory" and when free memory runs
load, reduce cache size dynamically. (improving low memory situations).
6. it should get a gui to query cache state/contents and display visually.
this would be awesome to have a list of thumbnails that show whats in the
cache, how many referencesa they have, last active timestamps etc.
blah blah.
please let me know if the build is broken asap though as i will vanish
offline for a bit in about 24hrs...
SVN revision: 40478
* fix fullscreen_set() and borderless_set() functions in ecore_win32
* change SetWindowLong() to SetWindowLongPtr() as it is deprecated
* better error management when dealing with SetWindowLongPtr()
* remove useless SendMessage() calls
* other minor fixes
SVN revision: 40354
thx, but you committed rev 1 of the patch. I send out an updated patch
since the function naming did not follow "e" style. Attached patch
renames the functions accordingly. Please apply.
SVN revision: 40322
Hi
This patch adds two new functions, ecore_pipe_close_read and
ecore_pipe_close_write, to ecore_pipe. The purpose it to enable
ecore_pipe to be used together with fork (see example below).
The patch also handles if the read or write end of the pipe closes.
SVN revision: 40305
Rodrigo Cesar Lopes Belem
Carsten Haitzler
Gustavo Sverzut Barbieri
Davide Andreoli
Vincent Torri
Daniel Kolesa
Massimiliano Calamelli
Mike Frysinger
Jaime Thomas
Rafael Antognolli
Viktor Kojouharov
Luis Felipe Strano Moraes
Iván Briano
Lars Munch