While this kind of API seems to make sense with smart objects
(relative coordinates), it is currently not used apart from
the smart object class itself.
So, for now, I'm moving this to legacy to clean up Efl.Canvas.Group
and we can later add the equivalent in a clean "group" API.
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
Similarly to group_color_set, group_clip_[un]set should not
exist and should be a result of efl_super and inheritance.
This patch also removes clip_unset from the EO API and keeps
only clip_set(NULL). The reason is that it will avoid bad overrides
of clip_unset() vs. clip_unset(NULL). This also simplifies the code
a bit. Ideally we should be able to reintroduce clip_unset in EO
if we can have a "@final" tag (like java's final keyword), to
prevent overrides.
Widgets should simply override efl_gfx_color_set and call
super all the way up to evas object.
Legacy compatibility with call interceptors and early call
abortion (eg. delete_me or obj->layer == NULL) are implemented
with an internal call. See the previous commit introducing the
API.
This is a poor man's solution to get rid of group functions such
as clip_set, clip_unset, color_set, etc... See the following
commits.
This API needs to be EAPI for elementary but shouldn't be used
outside EFL. This is required purely for legacy compatibility.
Here's the call flow, inside show(obj):
1. if (intercept_show(obj)) return;
2. show(super(obj));
3. do other stuff
Most of the smart functions "Efl.Canvas.Group.group_xxx" should
not exist and be overrides of the base object function instead.
Cleaning this up is necessary if we want an EO API for custom
smart objects. This patch is the first attempt at removing a
method (the simplest one).
As for no_render, I wonder if propagating to the children
really is necessary. evas_render should skip them already.
When we destroy outputs, we should be freeing the Output's Modes also
as that was previously allocated memory.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: when transition animation is working, sometimes one pixels loss occurs.
Reviewers: cedric, woohyun, jpeg, raster
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4341
Summary:
Built from sources version of evil is already added to linker flags and
adding extra -levil makes build fail if evil is not already installed in system.
Looks like this flag was here from old times when all efl libraries were separated.
Reviewers: vtorri, NikaWhite
Reviewed By: NikaWhite
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4332
Summary:
If the pixels of image object has updates
via native_suface_set api with TBM surface,
does not update on screen(no rendering)
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4340
Some fixes for OS X.
This series fixes two problems pointed by jayji and some other
compiler warnings.
Patches by iscaro.
Differential Revision: https://phab.enlightenment.org/D4339
This merges a rewritten Eolian C generator which replaces the previous
generator. The old generator did not properly reflect the design choices taken
in the Eolian library, which resulted in a sub-par codebase that was a lot more
complicated than it had to be which resulted in worse maintainability.
The new generator aims to remedy that; it has much simpler design that relies
on the Eolian library more and doesn't take certain design choices that were
made previously.