So yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
now they can be trule async hopefully stopping things like application
menu from stalling while loading icons header... which is really nasty
with svg's. this actually makes icons async by default which is really
EXACTLY what you want. this also prepares for later making edje loads
async.
@feature
Commit fd8d41a2a6 introduced a void return in a
non void function. On gcc this only produced a warnigns but it was a hard
error on clang and should be fixed.
00:25:24.906 src/bin/e_fm.c:1523:15: error: non-void function 'e_fm2_icon_file_get' should return a
value [-Wreturn-type]
00:25:24.950 if (!file) return;
fm icon info is transient because fm icons are transient. files may
get deleted, added or removed on the fly. keeping icon info around for
things like the popup is asking for tyrouble and does create trouble.
so look it up each time based on filename string. safe!
this fixes T4716 and fixes T4798 (they are the same bug basically).
Currently, the context menu will show a separator before the background and overlay items even if there is nothing before, such as on the favourites pane.
@fix
Gcc 6 was spitting a nasty little compiler warning here:
src/bin/e_fm.c: In function ‘e_fm2_icon_geometry_get’:
src/bin/e_fm.c:2354:4: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
if (x) *x = 0; if (y) *y = 0; if (w) *w = 0; if (h) *h = 0;
^~
src/bin/e_fm.c:2354:19: note: ...this statement, but the
latter is misleadingly indented as if it is guarded by the ‘if’
if (x) *x = 0; if (y) *y = 0; if (w) *w = 0; if (h) *h = 0;
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Sometimes, trying to go to the parent directory wouldn’t work and end up showing some garbage. Unfortunately, the code ended up not NULL-ending the path, which made searching for the path separator buggy.
this should fix open file handles on unmount by flushing caches first.
not great, but works. long-term have evas not keep file handles open
for 0 refcount cached items.
previously, beginning a drag with the left button, then pressing and
releasing another button would result in the drag terminating without
the original button being released
str(n)dupa are GNU extensions that duplicate a string, using an alloca'd
buffer. This patch removes their definitions from e.h (which should only
contain E's own API, without fallback definitions for libc functions)
which were wrong anyway (they failed in cases where str(n)dupa was an
actual function, not a macro).
Instead, we replace them depending on context with alloca+memcpy+strlen
or a static buffer (used in contexts where we are sure that the buffer
will contain the string entirely)
@fix
this speed sup dir listing in efm drastically. first the e fm back end
uses an io thread that just spools through everything fast and sends
it over the mainloop to then send by ipc to e.
and on the e side we no longer use the heavy file internal magic using
api calls that wander all over a file for magic numbers - this is
insanely slow and brings listing to a crawl.
Summary:
There were a few crash cases during drag and drop.
- move file in Desktop using efm,
- move file in same directory using differnt efm
The root cause is icon finding logic. efm finds icons based on URI string.
But, the found icon could be different with selected one since there could be multiple efm in same directory.
Therefore, this patch filter out icon which is not selected icon.
Fixes T1364
Test Plan:
case 1. open efm -> goto desktop -> move file from ~/Desktop to ~/Desktop/folder
case 2. open two efm -> goto same directory in two efm -> move file to {currentdirectory}/folder in any efm
Reviewers: raster, zmike
Subscribers: cedric, seoz
Maniphest Tasks: T1364
Differential Revision: https://phab.enlightenment.org/D1331
Summary:
There was no checking about absolute path of symbolic link
In case of symbolic link, use real link (absolute path) and set sd->dev as "/"
Fixes T1365
Reviewers: raster, zmike
CC: seoz, cedric
Maniphest Tasks: T1365
Differential Revision: https://phab.enlightenment.org/D1147
so e is using eo... and something in eo changes... and e fails to
compile entirely.... there are hacks to use eo... and this is not good.
eo is still in a beta state. that means any usage of it can (and
will) break. this is a problem for e. if e uses eo, then eo breaks in
an efl upgrade, e breaks. we can't really have that. we already hit
this problem in terminology with the app server code in elm. so let's
just not use eo in e until it's stable.
this removes eo usage in all places, with the e_menu code having a
small isedje() func due to some of its code paths doing special things
based on if the obj is an edje one or not as opposed to just a simple
"only emit if its an edje obj".