Summary:
Instead of surrounding all the #include "*.eo.h" lines in Efl.h
with #ifdef EFL_BETA_API_SUPPORT, include these files unconditionally, but mark
all classes as @beta in the eo files.
This will allow taking them out of beta one by one as we deem them stable enough.
Otherwise, the current procedure involves moving the #include line out of the
ifdef block, which is cumbersome and messes include order.
Depends on D7950
Fixes T7692
Test Plan: Nothing changes
Reviewers: zmike, bu5hm4n, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7692
Differential Revision: https://phab.enlightenment.org/D7951
This patch adds support for map with more than 4 points.
However, we only support points with multiples of 4.
This also adds efl_gfx_map_point_count_set/get APIs to
set number of points.
@feature
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.
It relies a bit on evas legacy APIs and will only work on
evas objects (Efl.Canvas.Object) for now.
The main difference with Evas_Map is that there is no
separate map object, as the functions apply directly to
any canvas object.
For convenience, most functions will automatically populate
the map if there was no previous map info. While this may
be convenient, the object's size changes still need to
be tracked to update the map info.