| Age | Commit message (Collapse) | Author |
|---|
|
This isn't meant to be installed. The canvas API in EO is based around
the interfaces Efl.Canvas and the widget Efl.Ui.Win. Anything else is
not EO (eg: ecore_evas, evas, ...)
Note: evas_canvas3d is the last remaining thing that is installed along
EO files, but those are all beta APIs.
|
|
Reviewers: jpeg
Subscribers: jenkins, cedric
Differential Revision: https://phab.enlightenment.org/D5357
|
|
|
|
|
|
Efl.Animation.Group.Sequential is a class for animations started in
sequence.
Efl.Animation.Object.Group.Sequential is a class which provides
methods for an object of Efl.Animation.Group.Sequential.
The objects added into the sequential group animation object start
in sequence.
|
|
Efl.Animation.Group.Parallel is a class for animations started in
parallel.
Efl.Animation.Object.Group.Parallel is a class which provides methods
for an object of Efl.Animation.Group.Parallel.
The objects added into the parallel group animation object start in
parallel.
|
|
|
|
Efl.Animation.Group is an abstract class which provides methods for
group animations such as parallel and sequential group animations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Efl.Animation.Object is a class which starts or cancels animation.
Efl.Animation.Object instance is created by Efl.Animation instance.
So Efl.Animation.Object instance contains animation properties from
Efl.animation instance.
Animation properties are set by using Efl.Animation instance and the
animation is started or cancelled by using Efl.Animation.Object.
|
|
Efl.Animation is a class which contains basic properties of animation
for Efl.Canvas.Object.
|
|
The functionality is now merged inside the core Group class, which will
allow us to clean up its API.
|
|
You may need to remove your installed directory to avoid conflicts
|
|
Originally it was its own object.
There are some valid claims that there is no justification for it to
remain an object.
Furthermore, it's apparent that it added little benefit: changes of
each cursors, in practice, triggered a query for all objects of the
same textblock. There wasn't real advantage to have a finer resolution
of controlling the cursors with their own events.
This ports back a lot of code, and changes a lot of other code in the
higher-up widgets, such as Efl.Ui.Text and co.
The usage was replaces from:
efl_canvas_text_cursor_char_next(cur_obj)
to
efl_canvas_text_cursor_char_next(text_obj, cur_obj)
that is, it is an operations on the TEXT OBJECT, rather than on the
(now removed) cursor object.
So, one less efl object to worry about now.
Hopefully, the port went smooth.
|
|
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
|
|
Signed-off-by: Amitesh Singh <amitesh.sh@samsung.com>
|
|
Now evas_types has nothing but canvas3d definitions.
Fixes T5312
|
|
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
|
|
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4809
|
|
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4804
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
|
|
Test Plan:
- There are other grammatical errors, but I'm focusing this patch just
on pluralization-related issues to ease review and make it clearer if
I've introduced any inaccuracies.
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4784
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
|
|
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4735
|
|
|
|
This removes:
Efl.Event interface
And renames:
Efl.Event.Input -> Efl.Input.Event
Efl.Event -> Efl.Input.Event (merged)
Efl.Event.Pointer -> Efl.Input.Pointer
Efl.Event.Key -> Efl.Input.Key
Efl.Event.Hold -> Efl.Input.Hold
This also moves some interfaces from efl/ to evas/ where they
belong better.
This allows renaming Eo_Event to Efl_Event.
|
|
This fixes the build for older versions of E.
|
|
Evas map is not translated to proper eo apis yet.
Efl.Canvas.Map will be a mixin implementing the evas map
API in a bindable API.
|
|
|
|
Evas.Common_Interface not only had a bad name, it also
wasn't in line with how we can get a loop object, for
instance.
Use eo_provider_find in each implementing class.
|
|
One step closer to make the EO inheritance tree look like
it's all Efl.
|
|
|
|
This is legacy stuff. I wish we could hide it from our inheritance
entirely. Instead, just make it abstract, remove all functions from
eo (doable here) and rename with the keyword "internal" in the new
ugly java style name.
|
|
The text cursor is now an eo object. Consult the efl_canvas_text_cursor.eo file
for the API.
@feature
|
|
The implementation depends on creating different code paths from the now-legacy
behavior of text appending.
The annotation system introduced in this commit replaces the current way of
applying formats on text.
Up until now it has been quite a hassle for the user to control the formats, as
it required keeping track of the format positions with an opener and closer
formats almost every time (with the exception of own-closing formats).
The combination of Efl.Text API along with the Efl.Canvas.Text annotation API
essentially replaces the capabilities of the old format.
There is additional annotation API to allow more control, so be sure to check
the documentation/.eo files and the wiki page of Efl.Canvas.Text.
The style API now accepts actual strings of format style. There is not longer
need to instantiate as style with style_new() followed later by style_free().
@feature
|
|
Not sure this is a good name for this interface, but it
definitely doesn't belong inside lib/evas/
Thanks Jiyoun for the question / report :)
|
|
Vanvas3d and VG are still conisereed beta. For the rest we are going to sort
this out over the next days/weeks. Either EO API flag removed or put under BETA.
|
|
This merges window and evas events into a single name.
Some events are marked as @beta as they shouldn't really be
part of our EO API.
|
|
|
|
|
|
|
|
|
|
Event prefix is efl_ui:
EFL_UI_EVENT_CLICKED
EFL_UI_EVENT_CLICKED_DOUBLE
...
The event prefix could be reduced to efl but I personally
prefer with UI.
|
|
Thanks @ami
|
|
Make it abstract.
And add Evas.Image as a legacy-only class.
|
