Summary:
- Changed beta methods guards from CLASS_NAME_GUARD to
EFL_BETA_API_SUPPORT to use the same scheme as C.
- Removed some includes to Efl_Ui.h from the examples. These were
causing C's efl_part_get to not be generated due to EFL_PART_PROTECTED
not being yet defined (it is defined in Elementary.hh, included
afterwards). This was leading to Efl.Part.impl.hh trying to use a
non-existent method.
Fixes T7716 partially (missing stringshare issue)
Test Plan: make examples
Reviewers: stefan_schmidt, felipealmeida, zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7716
Differential Revision: https://phab.enlightenment.org/D8284
Summary:
these types are not currently being released and eolian should not have
generated legacy code using them
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8288
Summary:
This enables all the checks unconditionally, without ignoring
classes that don't have an Efl namespace. This required a lot
of beta marking to make it build. It most likely doesn't
mark types correctly, as that is not fully enabled yet.
Reviewers: zmike, cedric, segfaultxavi, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8266
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:
This commit changes the beta ness of a few types, those types are
looking quite stable. Edje types will likely not change. The
Efl.Gfx.Join types are actaully already stable since the last release,
since evas_vg was stable back then and those enums have been in there.
The elementary stuff looks a bit unthought, and we have the chance to
change the API in the backend, so maybe we want to not declare it
stable, but rather reintroduce the legacy types.
With this we can enable eolian generation of beta tags for types.
ref T7726
Depends on D8276
Reviewers: cedric, segfaultxavi, zmike, stefan_schmidt, q66
Reviewed By: segfaultxavi, q66
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7726
Differential Revision: https://phab.enlightenment.org/D8277
Summary: This now does work, and we can enable the full checks
Reviewers: segfaultxavi, cedric, q66, zmike
Reviewed By: q66
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8276
the tiles rotator is faster no matter what. this will fix D8099 by
movoing to tiled rotation and nuking the neon code and we end uop
being faster anyway in all cases.
@fix
Summary:
With this we can drop the getenv in eolian, and enable beta checking per
default.
ref T7584
Depends on D8274
Reviewers: segfaultxavi, cedric, q66, zmike
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7584
Differential Revision: https://phab.enlightenment.org/D8275
Summary:
those types are now used in stable API, we should mark it stable.
ref T7584
Reviewers: segfaultxavi, cedric, q66, zmike
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7584
Differential Revision: https://phab.enlightenment.org/D8274
Summary:
there is no sense to have this outside beta, noone should really use
this. It is only meant for debugging purposes.
ref T7726
Depends on D8271
Reviewers: segfaultxavi, cedric, zmike
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7726
Differential Revision: https://phab.enlightenment.org/D8272
Summary:
in was not very descriptiv, move_in was concluded to be more descriptive
ref T7726
Reviewers: segfaultxavi, cedric, zmike
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7726
Differential Revision: https://phab.enlightenment.org/D8270
efl_ui_widget has a property called widget_parent. The setter for this
function is called is exactly once, and this is within the constructor,
to a value which is not even set to the actaul field parent_obj. Which
shows, that in the sitation right now, the setter of the property is a
bit disconnected and lags some real aspects.
As we are heading towards eo-api stabilization we should beat some sense
into this setter, as people using our classes might overwrite the setter
and except calls to it, whenever the widget_parent is changed, and
implementation as in elm_menu show that this might makes sense sometime.
In order to achive this, the sub_object registering code of elm is
adjusted a bit.
sub_object_add/del is now used to differenciate between evas objects and
efl.ui.widget objects as subobject. In case of a widget, the
widget_parent of this object is set, most of the widget specific code is
then executed in the actaul setter. In case of an evas object, the
parent reference is added. In the end both end up in the subobject
children list. The later is also a requirement for widget_parent_set to
be successfull.
ref T7553
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8031
before the widget_parent have been only set once. The call to the set
was in the constructor and carried the efl_parent. In the next commit
widget_parent is getting a refactor, which gives it more meaning, where
it is actaully called, which means, the behaviour will change. In order
to not break every existing usage of the here changed widgets, we move
the code to the constructor, and feed it with the efl_parent, just like
before.
Differential Revision: https://phab.enlightenment.org/D8041
Getter are usually not modifying there object. This is going to put a strong
limit on what a getter property for MVVM is, as it will prevent any side
effect on getting a property from a View.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7969
This means that all property that are registered in the reflection table of
any Eo class will be available for binding with a model. This will increase
the amount of useful binding quickly.
Reviewed-by: Vitor Sousa da Silva <vitorsousa@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D7941
this sucks but we've been using these types in legacy headers for years
and it's not something we can rush in a fix for
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8248
Summary:
these are all types that we do not currently want to release
Depends on D8102
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8241
Summary:
This removes all Eolian API that deals with handling of legacy
code. It also removes the code using it in the generator as well
as bindings, but for now keeps generation of .eo.legacy.h types,
as there are still instances in our codebase where things are
otherwise broken. We can remove the rest once that is resolved.
Reviewers: zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8255
Summary:
This event can just be renamed, no need to handle legacy. The reason for
this, that this event is used to map to EVAS_CALLBACK_ enum fields,
which means, the legacy names of the event does not matter.
ref T7476
Reviewers: cedric, segfaultxavi, zmike, stefan_schmidt
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7476
Differential Revision: https://phab.enlightenment.org/D8242
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