Summary:
This patch extends efl_canvas_vg_object class to implement efl_gfx_frame_controller
to suppor any playable animation on it.
Plus, vector object takes care of lottie animation by using json loader.
it's caching mechanism is changed to cache only static frame, not all frames.
vg_cache supports json loader and make it animation request properly.
This feature has been stabilized enough, it's using in Samsung Galaxy Watch active product,
proved its stability enough.
Depends on {D8940}
Co-authored-by: JunsuChoi <jsuya.choi@samsung.com>
Reviewers: #committers, jsuya
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8941
This reverts commit c876ac52d9.
This is not safe to remove - this breaks enlightenment. perhaps test
with the reason efl exists in the first place before delcaring it
safe? specifically this removed some function symbols in
efl_canvas_event_grabber_eo.legacy.c ...
Summary:
Since the removal of legacy interfaces from eo files, these files
contain nothing useful, and can safely be removed. One exception
is `efl_ui_layout.eo.legacy.h`, which will require more involved
work to remove, since a lot of things seem to depend on the
Efl_Ui_Layout typedef being present, wrongly (i suspect this
will break everything with `EFL_NOLEGACY_API_SUPPORT`).
Reviewers: cedric, zmike, bu5hm4n
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8251
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D8107
Summary:
api naming in efl uses 'del' when deleting an object and 'remove' when
removing something from an object
ref T7554
Depends on D8034
Reviewers: segfaultxavi, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7554
Differential Revision: https://phab.enlightenment.org/D8035
this is now done via Efl.Object.event_freeze / Efl.Object.event_thaw.
ref T7555
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8011
it was decided that this property should be internal. So now it is
internal.
ref T7555
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8010
Summary:
For clarity, since there are all kinds of maps, including a navigation map
widget.
Also, corrected some misspellings.
Test Plan: make && make check && make examples all work
Reviewers: cedric, zmike, bu5hm4n
Reviewed By: cedric
Subscribers: Jaehyun_Cho, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7564
Differential Revision: https://phab.enlightenment.org/D7974
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:
Following our naming rule, rename to like other primitives.
i.e. efl_canvas_rect, efl_canvas_image, efl_canvas_vg ...
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7013
Summary:
It has been widely used for quite some time now.
Fixes T6889
Test Plan:
Manually built the evas-vg-simple.c and evas-vg-batman.c examples after
removing the manual define of EFL_BETA_API_SUPPORT and EFL_EO_API_SUPPORT
that they have at the top.
Reviewers: ajwillia.ms, zmike
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6889
Differential Revision: https://phab.enlightenment.org/D6230
also implement Efl_Canvas.objects_at_xy_get
note that any function which returns an iterator cannot be @const since
it's necessary to wref the object to ensure the iterator's lifetime
remove eo apis pointer_in, pointer_device_in, pointer_inside_get &
pointer_inside_by_device_get and add legacy APIs for
pointer_inside_get & pointer_inside_by_device_get.
These four APIs do almost same things.
This removes the internal function pointer for scale_update. This makes
all relevant classes implement the scale API in EO.
This removes the duplicate function in Efl.Canvas.Object and only uses
the one from Efl.Ui.Base interface.
This *seems* to be working as expected. Fingers crossed!
PS: I don't like the name Efl.Ui.Base. It's an interface for a few
common API's between Gfx, Canvas and UI levels... Maybe scale simply
doesn't belong there.
When a native surface ends up on a hardware plane, the caller needs to
know about it so it can prevent the resource from being destroyed while
on scanout (which may cause an implicit page flip and a stall), and
so it knows that the content may have changed usage domains.
This adds stubs for dealing with this - only for wl dmabuf right now, but
it may be useful for other surface types later.
adding an "event rect" is a common use case for rectangles, but I needed
a smarter event rect so I sent one off to school and it came back like this.
an event_grabber is a smart object which functions like a normal event rect
which has color(0,0,0,0), but with an important difference: it can have smart
members. event propagation works differently for an event_grabber:
normal:
event -> layer -> smart(obj1,obj2,obj3) ->(?) other objects
in this case, obj1,obj2,obj3 are all "inside" the smart object and their stacking
will always be considered as being inside the smart object. rendering is also
tied to the smart object in this case, as is clipping.
an event which reaches a smart object will be sent to the objects inside,
and then may continue through the smart object if there are no objects which
block repeating.
event_grabber:
event -> layer -> event_grabber -> obj1,obj2,obj3 -> STOP
in this case, obj1,obj2,obj3 are unmodified after being added to the event_grabber
and can be stacked, rendered, and clipped completely independently of the
event_grabber.
the event_grabber is considered an "event_parent" for this case. member objects
are not "inside" the event_grabber, and they are unable to receive events on
their own. instead, the event_grabber, which must be stacked above all its
members, receives events and propagates them top->down through its member objects.
if none of the member objects block the repeat of an event then the event will
still be blocked from further propagation past the event_grabber.
object lifetimes are independent of the event_grabber; deleting the event_grabber
has no effect on its members.
@feature
This size hint is only used by naviframe, which is not part of
our EO widgets. I also believe it might be an even more confusing
hint than the others.
I kept the typedef as is in Evas_Legacy.h in case an app is
written using EFL_GFX_ instead of EVAS_...
Hermet Park
Daniel Kolesa
Xavi Artigas
Carsten Haitzler
Daniel Kolesa
Mike Blumenkrantz
Marcel Hollerbach
Mike Blumenkrantz
Amitesh Singh
Jean-Philippe Andre
Andy Williams
Cedric BAIL
Derek Foreman