lots of formatting cleanups
move udev extern into private header
another filter added to find_by_type to avoid some disks that randomly crop up with MOUNTABLE
SVN revision: 53745
Description of changes / revisions (not all of them, I just picked some to
explain the names inclusions)
bdilly
Bruno Dilly <bdilly@profusion.mobi>
edbus -> r42081, r39884, r44581, r40463
python-elementary -> r52765, r52389
edje -> r46548, r49242
editje -> r52520
fidencio
Fabiano Fidêncio fidencio@profusion.mobi
elementary / python-elementary -> fix elm_<widget>_{icon,content}_set - r49706;
add externals - r{47649,47647,47645}
edje / python-edje -> lot of work on edje_edit
glima
Gustavo Lima Chaves <glima@profusion.mobi>
elementary -> added widgets
edje -> lot of work on edje_edit
helen
Helen Fornazier <helen.fornazier@profusion.mobi>
elementary -> elementary key events on widgets
editje -> undo / redo
jprvita
João Paulo Rechi Vita <jprvita@profusion.mobi>
e_dbus-> r47399 , r47398, r47397, r47336, r47330
padovan
Gustavo F. Padovan <padovan@profusion.mobi>
e_dbus-> r46365-r46373, r47114-r47119
SVN revision: 53682
This is an attempt to fix the epoll/fork() issue reported to me where
we end up with a single epoll fd shared between two processes after a
fork() in E.
I've tested with elementary test in epoll and non-epoll combinations,
and all appears to be well. Please check it solves the issue you saw,
and reformat the code as you see fit... ;-)
SVN revision: 53670
I don't expect anything to break, but if mouse or keyboard events suddenly
disappear, feel free to revert this patch while blaming cedric or discomfitor.
SVN revision: 53583
Patch by Patch by Raphael Kubo da Costa <kubo@profusion.mobi>
As discussed on the development mailing list, we should accept a
double instead of a time_t for consistency with the rest of the API.
Some apidox has been added too, and as a result
ECORE_CON_URL_TIME_LASTMOD has been removed, since it does not make
much sense (it is an HTTP response header).
SVN revision: 53572
when trying to free the mode_info. Not much functional difference with
this commit except that we do not call strndup if the nameLength is
<= 0.
SVN revision: 53477
move or resize of an obj WHILE in the middle of a move or resize
already - some weird case someone has come up with where this happens
and things like smart clipped's "move relatvie by dx, dy" totally
screw up then. it's a totally unexpected case though. some circular
action has been created that logically shouldn't have existed.
SVN revision: 53434
When we push a memory to the trash stack we mark it as unaccessable. So we
should mark it as accessible before returning it to the user.
SVN revision: 53427
Because mempools generally allocate a big memory area and distribute chunks of
that area to the users, valgrind can not know about logical invalid access. By
using some valgrind macros we can tell valgrind about mempools and which area
can be accessed or not.
To start with I have just done valgrind integration on chained mempool but soon
it will be done for one_big too.
The code below is an example on which valgrind wouldn't complain without this
patch:
@code
#include <Eina.h>
int
main(int argc, char *argv[])
{
int i, *pool[4];
Eina_Mempool *mp;
eina_init();
mp = eina_mempool_add("chained_mempool", "test", NULL, sizeof(int), 4);
for (i = 0; i < 4; i++) {
pool[i] = eina_mempool_malloc(mp, sizeof(int));
*pool[i] = i;
}
printf("Valid mp pointer: pool[0] = %d\n", *pool[0]);
eina_mempool_free(mp, pool[0]);
printf("Freed mp pointer: pool[0] = %d\n", *pool[0]);
for (i = 1; i < 4; i++)
eina_mempool_free(mp, pool[i]);
eina_mempool_del(mp);
eina_shutdown();
return 0;
}
@endcode
SVN revision: 53405
match ecore_thread_feedback_run better.
NOTE: I know it breaks API/ABI compatibility for that call,
but that's the only sane solution I could found.
SVN revision: 53370
I was still reaching uninitialized usage and it does make sense, as
the parent thread could be postponed until the new is started, then
the scanner/worker thread hits an error (ie: directory permission
denied) and it is cancelled before the main thread had time to get the
thread attribution (common->thread).
I'd like someone to look at it. Probably this is NOT the right way to
fix. Likely what we should do is send a "ready! start working" command
from the main thread to the worker thread and avoid such thing.
==5848== Conditional jump or move depends on uninitialised value(s)
==5848== at 0x42808CD: ecore_thread_cancel (ecore_thread.c:534)
==5848== by 0x4238558: eio_file_thread_error (eio_single.c:35)
==5848== by 0x42368FC: _eio_file_direct_heavy (eio_file.c:78)
==5848== by 0x42800F3: _ecore_feedback_job (ecore_thread.c:247)
==5848== by 0x4280398: _ecore_thread_worker (ecore_thread.c:317)
==5848== by 0x41FE16AE: start_thread (in /lib/libpthread-2.11.2.so)
==5848== by 0x41F3295D: clone (in /lib/libc-2.11.2.so)
==5848== Uninitialised value was created by a heap allocation
==5848== at 0x400793F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5848== by 0x4237991: eio_file_direct_ls (eio_file.c:566)
==5848== by 0x8051C81: ephoto_directory_thumb_add (ephoto_directory_thumb.c:131)
==5848== by 0x804D4AB: _ephoto_thumb_dir_icon_get (ephoto_thumb_browser.c:75)
==5848== by 0x405F4C8: _item_realize (elm_gengrid.c:807)
==5848== by 0x405FE77: _item_place (elm_gengrid.c:980)
==5848== by 0x40610F6: _pan_calculate (elm_gengrid.c:1199)
==5848== by 0x418CA38: evas_call_smarts_calculate (evas_object_smart.c:843)
==5848== by 0x41B23B2: evas_render_updates_internal (evas_render.c:971)
==5848== by 0x41B3DA1: evas_render_updates (evas_render.c:1414)
==5848== by 0x42E4550: _ecore_evas_x_render (ecore_evas_x.c:406)
==5848== by 0x42DDD2C: _ecore_evas_idle_enter (ecore_evas.c:47)
SVN revision: 53340
==17972== Use of uninitialised value of size 4
==17972== at 0x42918DB: ecore_thread_cancel (ecore_thread.c:536)
==17972== by 0x4249558: eio_file_thread_error (eio_single.c:35)
==17972== by 0x42478FC: _eio_file_direct_heavy (eio_file.c:78)
==17972== by 0x42910F3: _ecore_feedback_job (ecore_thread.c:247)
==17972== by 0x4291398: _ecore_thread_worker (ecore_thread.c:317)
==17972== by 0x41FE16AE: start_thread (in /lib/libpthread-2.11.2.so)
==17972== by 0x41F3295D: clone (in /lib/libc-2.11.2.so)
==17972== Uninitialised value was created by a heap allocation
==17972== at 0x400793F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17972== by 0x4248991: eio_file_direct_ls (eio_file.c:566)
==17972== by 0x8050B8E: ephoto_directory_thumb_add (ephoto_directory_thumb.c:127)
==17972== by 0x4061570: _item_realize (elm_gengrid.c:807)
==17972== by 0x4061E27: _item_place (elm_gengrid.c:980)
==17972== by 0x4062875: _pan_calculate (elm_gengrid.c:1199)
==17972== by 0x419DA38: evas_call_smarts_calculate (evas_object_smart.c:843)
==17972== by 0x41C33B2: evas_render_updates_internal (evas_render.c:971)
==17972== by 0x41C4DA1: evas_render_updates (evas_render.c:1414)
==17972== by 0x42F5550: _ecore_evas_x_render (ecore_evas_x.c:406)
==17972== by 0x42EED2C: _ecore_evas_idle_enter (ecore_evas.c:47)
==17972== by 0x428C85F: _ecore_idle_enterer_call (ecore_idle_enterer.c:129)
SVN revision: 53336
<discomfitor> ecore_con_url.c:963:14: warning: too few arguments for format
<rakuco> ah, missing a , filename there
<rakuco> can you commit that
SVN revision: 53334
file_offset_bits .. CHANGES the size of structs like dirent? so if u
do it differently in different c files... u end up with.. GASP
different structs with different sizes! dont do this. unify everything
into eio_private.h so its at least CONSISTENT for eio's internals.
SVN revision: 53322
I needed to bump minor file format version, but it will only
change behaviour for people using alias for part and they
couldn't use the signal emitted by them.
SVN revision: 53305
a super-simple (but full featured) pong game, fully written in embryo,
in the style of the original game.
To run it, like all the other examples, just go in the doc/examples folder and do:
edje_cc embryo_pong.edc && edje_player embryo_pong.edj
Have fun ...beating the ""AI"" is really difficult ;)
SVN revision: 53278
Depending on the option being set by curl_easy_setopt, a return value
different from CURL_OK can be returned (the same applies to curl_multi_*
and CURLM_OK).
This commit checks the return value from those calls and usually
displays an error message with ERR() and returns -- in some cases, an
error is shown but the function does not immediately return.
A few lines of code have also been moved around in order to make
returning from functions as harmless as possible.
By: Raphael Kubo da Costa <kubo@profusion.mobi>
SVN revision: 53275
By checking for the validity of the Ecore_Con_Url struct before anything
else and merging some if's, the code can get much cleaner.
By: Raphael Kubo da Costa <kubo@profusion.mobi>
SVN revision: 53274