This will be properly implemented by the subclasses. In particular,
map/unmap will be used where it makes sense, and data_get/set will
be limited to Efl.Canvas.Image and Surface.
A small hack to the toolchain allows us to generate enums with eolian
for use by Eet and Emile (internal or otherwise non-eo libraries).
Thanks to how BUILT_SOURCES works, the eo.h files required by Emile
will be generated before they are used.
This adds a partial dependency on eo for eet and emile:
- package dependency
- include dependency
There is no library link dependency.
An otherwise good looking macro triggers a warning with clang,
because of self comparison of constants (always true or always
false). Let's just silence the warning in this specific spot
with a pragma.
Summary:
Support hexadecimal color code in EDC.
Four types of color code are acceptable.
All values below mean 'Red'. (255 0 0 255)
color: "#F00";
color: "#F00F";
color: "#FF0000";
color: "#FF0000FF";
Color code tables are usually provided with hexadecimal numbers.
Supporting hexadecimal color code will allow developers to skip
manual conversion hex to decimal.
Test Plan: Test case will provided with seperated commit.
Reviewers: cedric, jpeg, raster
Reviewed By: raster
Subscribers: raster
Differential Revision: https://phab.enlightenment.org/D3831
several draw funcs keep a static Cutout_Rect *rects = NULL; variable
to cache cutout rects to avoid re-allocating them a lot etc. this is
fast and handy but we may use these from multiple threads. thats bad
.... mmmkay. so this fixes it the dirty way - makes them thread local.
:)
this fixes T3348 - the crash mentioned by @zmike
@fix
so there was/is a case where when an elm window is resized from
outside, it will happen to use the last known size (maybe old) and end
up requesting a resize to that size again itself. it basically
triggers its own resize request as a result of resize events. this
fixes that and stops the loop
@fix
so i had a separate flat theme i was working on but i just can't keep
up with changes so i'm just putting in some of the nicest bits here
slowly like nicer shadows.
@feat
after elm merge build broke with things like this enabled. this fixes
that.
i'd like to bring up one issue here. ecore_drm is not a good
abstractionlayer. it requires libdrm and other headers from system and
it should have abstracted things so the system libdrm is hidden/not
needed for build (or even perhaps at runtime and this could be rolled
into ecore_drm). this is how ecore_x is... and ecore_fb etc.
This make elementary break the modularity of the underlying layer. I haven't looked
at what is going on here, but basically if you have a wayland, a drm, whatever backend
turned on. You need elementary to be link against that ecore_* directly. This means
we are lacking in abstraction in Ecore_Evas and are dlopening to much library at
startup. This needs to be improved in the future.
I am guessing this is related to maybe DnD and C&P.
These binaries do not need the libtool library flags. This could actually lead
to problems. We already got a warning for one:
libtool: warning: '-version-info' is ignored for programs
this resolves the issue of all elm windows being created at 1x1 and
immediately resizing to another size after being shown, causing all
kinds of failures in various environments
@fix
Summary:
commit f9e6550468 Changed the RENDER_SYNC
the default behaviour (previously it was something you had to
change source code to set that way)
This leads to massive amounts of tearing with the drm and gl_drm backends,
as they no longer wait for vblank before rendering.
I've changed the env var to ECORE_EVAS_RENDER_NOSYNC and made it
non-default as it used to be. People can set the env var to disable
frame limiting instead of having to set an env var to enable it.
Frame limiting really should be the default behaviour.
Reviewers: zmike, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3829
Summary:
Each Ecore_Wl_Input structure has there own keymap.
This keymap is struct xkb_keymap used in libxkbcommon lib and
the client can get this keymap from server in wayland system.
So if the client want to get keymap and use some libxkbcommon APIs,
use this API to get keymap.
Test Plan: Use this api after initialize wayland system.
Reviewers: raster, zmike, ManMower, devilhorns
Reviewed By: devilhorns
Subscribers: input.hacker, ohduna, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3819
Summary:
add null check in _style_match_tag()
if evas_object_textblock_text_markup_set() is called with markup text before setting style,
segmentation fault is occurred in _style_match_tag()
@fix
Test Plan:
Insert this situation to test suite
-> test id : evas_textblock_simple
Test for without this patch:
1. apply patch just "src/tests/evas/evas_test_textblock.c" partially.
2. $make check
Test for with this patch:
1. apply this patch completely (2 files)
2. $make check
Reviewers: id213sin, herdsman
Subscribers: Blackmole, cedric, jpeg
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D3818
Only Efl.Canvas.Proxy implements efl_canvas_proxy_source_clip_set.
Legacy image objects should use legacy APIs.
Thanks @zmike for the report and sorry I never saw the ERR myself :(
Fixes T3342
Please spend time looking at those as I had to do few stuff
manually and I may have borked some of them.
Side note question, why do we have ko.po and ko_KR.po ?
Jean-Philippe Andre
Jee-Yong Um
Carsten Haitzler
Daniel Zaoui
Yakov Goldberg
Cedric Bail
Stefan Schmidt
Mike Blumenkrantz
Tom Hacohen
Derek Foreman
JengHyun Kang
Jihoon Kim
Jiwon Kim
Oleksandr Shcherbina