Summary:
these hints are not strictly size-related, so renaming them is more consistent
with their actual function
ref T7563
Depends on D7968
Reviewers: segfaultxavi, cedric, bu5hm4n
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7563
Differential Revision: https://phab.enlightenment.org/D7977
Summary:
Efl.Ui.Layout namespace is removed to keep consistency with other
widgets.
Consequently, "Efl.Ui.Layout.Object" is renamed to "Efl.Ui.Layout" and
"Efl.Ui.Layout." is renamed to "Efl.Ui.Layout_".
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers, SanghyeonLee, woohyun
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7291
This reverts commit 2fb5cc3ad0.
Most of this change where wrong as they didn't affect the destruction
of the object. efl_add_ref allow for manual handling of the lifecycle
of the object and make sure it is still alive during destructor. efl_add
will not allow you to access an object after invalidate also efl.parent.get
will always return NULL once the object is invalidated.
Differential Revision: https://phab.enlightenment.org/D6062
Wherever the EO API is used, i.e. efl_add() is used to create evas
objects, we can skip the calls to set fill/expand.
This new set of defaults indeed saves ~60 loc in the tests (out of 115
objects created). I found only 3 cases where the align had to be set
manually (to the old default of 0.5).
See 1a1b8bc451
And e8b7f5f255
Ref T5301
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
usages.
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
Ref T5315
All windows should be standard, really. Except when using legacy
elm_win_add() or if type_set() was called with a specific type.
I dislike type_set...
Ref T5322
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.
The things you learn to love...
The situation was:
- An object is mapped (naviframe in an animation)
- One of its children has a mask
- The window is rotated by 90 or 270 degrees (landscape)
The mask glsl code to invert the x,y coordinate depends on the
screen rotation and this somehow was wrong.
Tested on Tizen and in elm_test "Masking", made with @jiin.moon.
@fix
Mike Blumenkrantz
Jaehyun Cho
Cedric BAIL
Xavi Artigas
Carsten Haitzler
Jean-Philippe Andre
Amitesh Singh