this flag must not be set partially for a project in this way or it will cause build failures on some systems
furthermore, it should usually only be set either automatically when required by the build system or by a packager who knows that it is required
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
i know it's not that pretty, but this brings back the
E_CLIENT_HOOK_CANVAS_LAYOUT as there just is no viable replacement and
thus breaks 2 modules. this fixes T1402 - we chances are just that
this needs a separate hook point as it isnt a per-client but a
per-comp hook.
Summary: add the padding to the if clause
Test Plan: Set a padding and press WIN+Arrow keys
Reviewers: tasn
Reviewed By: tasn
CC: cedric
Differential Revision: https://phab.enlightenment.org/D1117
Summary:
jpeg image which has EXIF orientation meta data was not rotated properly in fm or preview.
@fix
Test Plan:
1. get in "efl/src/tests/evas/images/ in fm.
2. check whether Light_exif_*.jpg are properly rotated or not.
Reviewers: raster, zmike
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D1109
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".