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".
Chris Michael
Mike Blumenkrantz
Chidambar Zinnoury
Carsten Haitzler
Yomi
Daniel Kolesa
Chris Michael
Wonguk Jeong
Mike Blumenkrantz
Cedric BAIL