This removes Evas.Modifier_Mask from EO.
This introduces two new types instead:
- Efl.Input.Modifier
- Efl.Input.Lock
Those are enums, not strings, containing all the known and
currently supported lock and modifier keys. The enums are
bit masks.
This effectively removes the ability for an application to
create and handle specific modifier or lock keys - with EO
API (legacy compatibility is unchanged, of course). I wonder
who ever required this?
Such an ugly API. This is an API to match a string to a number,
build a bitmask from it, and then use that. The supported
strings are well known (should be enum) and would need a
recompilation (ABI update) to support anything new anyway.
This may be a bit more controversial...
But Evas_Coord really is just an int and all the internals
of EFL assume that the base coordinate type is a 32-bit int.
So this type is a bit redondant and can't easily be changed
to, say, a float or int64.
Ref T5312
We only need it in elm_config.
This removes the type Evas_Font_Hinting_Flags from EO,
as well as the functions font_hinting_set/get and
font_hinting_can_hint.
Ref T5312
Note: it seems the EAPI evas_touch_point_list_xy_get() was
lst at some point, as it doesn't appear in the headers anymore.
It looks like we fail to catch an ABI break! abi_checker didn't
catch this!?
Ref T5312
Summary:
Straightens up grammar and simplifies phrasing to make the functions
purposes clearer.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4874
Summary:
Removes extraneous newline, and fixes the indentation of the while
statement's sub-clause (which looked like a code error at first
glance).
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4875
Summary:
_layout_ellipsis_item_new() function deallocates "ellip_ti" and
allocates memory for new one. The local "ellip_ti" pointer should be
updated.
@fix
Test Plan: N/A
Reviewers: raster, cedric, herdsman, jpeg, woohyun
Differential Revision: https://phab.enlightenment.org/D4854
I've done this by translating "Flip Page" to this new set of
EO APIs. In particular, absolute coordinates need to be used
in some calls, and the map needs to be calculated between
get and set operations.
This required an adjustment of the raw_coord API as the flip_page
code does some math after reading and then writing to the map.
Same for color. Those two properties now act like commands (ie.
like the other gfx map functions).
This also introduces a duplicate set of APIs to handle absolute
coordinates. Other solutions included:
- Use an enum to specify the type of coordinates (but then the
unit of cx,cy varies between non-unit relative position and
pixel position. Also this adds an extra argument to all those
function calls.
- Pass a special value (an empty eo object) as the argument for
pivot. Same remark about the unit as above. This way was
deemed too confusing because of the weird object.
Those two options have been discarded after asking the opinion
of a few developers I could reach.
@feature
This implements an entirely new API model for Evas Map by relying
on high-level transformations on the object rather than an external
Evas_Map structure that needs to be constantly updated manually.
The implementation relies on Evas_Map.
To rotate an object all you need to do now is
efl_gfx_map_rotate(obj, 45.0, NULL, 0.5, 0.5);
Or with a C++ syntax:
obj.rotate(45.0, NULL, 0.5, 0.5);
Or even simply (with default arguments):
obj.rotate(45.0);
The map transformation functions are:
- rotate
- rotate_3d
- rotate_quat
- zoom
- translate (new!)
- perspective_3d
- lightning_3d
@feature
Manual points population will eventually be useless as the
map API will become more like a transformation API, where
the current object geometry doesn't matter as much as which
transformation is applied to it.
With the wayland backend, it is posible to have no seat connected
until later. This would lead to calling evas_object_pointer_mode_set
and fail without returning a boolean it was impossible to detect it
did fail. This patch correct it.
Summary:
Cleans up grammar, simplifies wording, and elaborates on some details
for better clarity. Assume the reader will already have a basic
understanding of reference counting and 3D graphics in order to avoid
overexplaining these concepts.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4837
This is needed by dmabuf engine fallback when it realizes it locally
allocated a buffer, has been rendering to it, but the compositor can't use
it.
So the engine copies its buffer contents into a new wl_shm buffer and
continues from there - however we need to make sure the async renderer
has finished first, so we don't copy a partial buffer.
This allows us to block for all previously submit actions in the render
queue to complete.
Summary:
when collecting the objects under a mouse pointer,
evas uses the geometry of an object to decide
whether the mouse pointer is inside the area of the object,
which is inappropriate for a mapped object.
so mapped objects don't receive mouse events when they should.
this patch fixes the issue.
Test Plan: A sample code will be added as comments
Reviewers: jpeg, raster
Subscribers: cedric, eunue
Differential Revision: https://phab.enlightenment.org/D4826
Test case:
elementary_test -to "Gesture Layer"
Just move the pictures around (eg. to the bottom). They could
disappear entirely.
This is because the geometry used was based on the smart
object "bounding box" rather than the mapped output.
@fix
This is the first step toward handling multi output. This patch
remove engine.data.output from Evas structure and use an Eina_List
for it instead. It also start moving code around to fetch an output
or an engine context (which are the same at the moment, but will be
split in a later patch).
Summary:
Rounding the sum of glyph's advance could cause inconsistency of
each glyph's positions. When Evas enables Harfbuzz library,
Each glyph's position has to be handled by only nearby glyphs.
But, currently, totally unrelated glyph's advacne could change
other glyphs positions.
ex) 1. "connect."
2. "Tap here to connect."
You can see different gap between "c" and "o" of word "connect".
It should be same even if there was a different text before the word "connect".
@fix
Test Plan: N/A
Reviewers: raster, herdsman, jpeg
Reviewed By: raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4782
Jean-Philippe Andre
Bryce Harrington
Cedric BAIL
Mike Blumenkrantz
Youngbok Shin
Carsten Haitzler
Derek Foreman
Stefan Schmidt
Jaeun Choi