There exist several flags to indicate whether an object should be animated, with inconsistent names:
Efl.Canvas.Layout.animation: bool indicating if Edje animations should be played
Efl.Ui.Spotlight_Manager.animation_enabled: bool indicating if page transitions should be animated
Efl.Canvas.Animation_Player.animation: Efl.Canvas.Animation object
This commit unifies all of them: "animated" is now a flag, and "animation" is an object.
Note: Animation_Player is in the process of being replaced by an "animation" property in the
Efl.Canvas.Object, hence the need for non-clashing animation flags.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10645
Summary:
This change `content_padding` parameter type to int from double for consistency
of size properties.
`scalable` should be handled in more common size API.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
ref T7864
Test Plan: ninja test
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7864
Differential Revision: https://phab.enlightenment.org/D10154
normally when you create a window, you just want to have it beeing a
basic window. If not you still can set the window type.
ref T8229
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D10049
after playing arround with the widget, we found out that it feels quite
weird to have a index, where most of the time you work with widgets.
We might want to add syntax suger in the future to make it easier to
just jump to the next element, or to the previous, but that still is to
be decided.
The event and the communication to the spotlight manager are still left
to be used with the index, reason for this is, that we might need to
fill there an invalid pointer, if a deletion is triggering an animation,
which seems quite weird. That needs further discussing.
Docx have been updated, the sitemarks about the shifting of the
active_index can be removed, as the element is not subject of change
during content adds/deletes.
ref T7991
Reviewed-by: Jaehyun Cho <jae_hyun.cho@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9813
this is the basic work for getting radio group as a single_selection
interface, which can be a part of mutli_selection. Which will come both
later on.
ref T8057
Differential Revision: https://phab.enlightenment.org/D9504
Previously, pop() does not unpack content if there is one content.
Now, pop() unpacks content without transition if there is one content.
Since there is no transition, NULL future is returned.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9450
we concluded min,reached and max,reached should be on every widget that
implements range_display. This here is the start of that work, the
events are moved, next commit fixes all widgets, the last commits
enables tests in the spec unit test.
ref T7897
ref T7895
Differential Revision: https://phab.enlightenment.org/D9371
To support blocking of scrolling movement, @property scroll_block has
been added to Manager_Scroll.
If scroll_block is set to be true, then scrolling movement by mouse
input is blocked.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9444
setting the parent here is usefull, as we can forgot about this object
then, and do not have to free the object by hand.
Differential Revision: https://phab.enlightenment.org/D9305
If pointer is processed by a container in its POINTER_MOVE event
callback, then clickable calls efl_ui_clickable_button_state_reset not
to be clicked by efl_ui_clickable_unpress.
e.g. Efl.Ui.Active_View.View_Manager_Scroll sets pointer processed in
POINTER_MOVE event callback not to click button during scrolling.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9204
View is something that is expected in the context of MVVM, so using it somewhere else is
going to lead to some confusion. Spotlight does descrive the objective of all of this
widget in actually a more explicit way as they all give the spotlight to one sub widget
at a time.
I have also renamed the View_Manager to be just Manager as the View there wasn't useful.