In EFL we have multiple hirachies of parts. One in Efl.Layout namespace
(alias edje) and one in Efl.Ui namespace. The seperation of these two
makes sense from the perspective of hiding functionality. However, a
functionality that we want to have on both is: we want to be able to
check which type of part this is. In order to do so, this commit
introduces a common interface, which allows that.
This is required because eo is currently undergoing some works, where
only APIs on a object are allowed, that are also inheriting its type,
which is normal in OOP, but sometimes, due to the lack of limitation, we
did that. This commit resolves one more case of that.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11516
this is usefull, as we now know which type of part we have, if a API
call does not succeed.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11463
Lots of EO files had the same information at the property and set/get level.
Removed the redundant bits, and moved to the property level the common ones.
Set and Get documentation should be used only to clarify setter-only or
getter-only behavior.
this has no relation to legacy and should not be included in legacy headers
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10227
Summary:
All legacy @since tags have already moved to the *.legacy.h files.
EO files are now devoid of @since tags (except some eldbus still
needed for legacy).
Upcoming patches will add @since 1.22 to those APIs which come out
of beta in this release.
APIs marked @beta do not need @since tags.
Test Plan: Everything builds, EO docs (like DocFX) have no Since tags.
Reviewers: zmike, bu5hm4n, lauromoura, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8430
Summary:
Instead of surrounding all the #include "*.eo.h" lines in Efl.h
with #ifdef EFL_BETA_API_SUPPORT, include these files unconditionally, but mark
all classes as @beta in the eo files.
This will allow taking them out of beta one by one as we deem them stable enough.
Otherwise, the current procedure involves moving the #include line out of the
ifdef block, which is cumbersome and messes include order.
Depends on D7950
Fixes T7692
Test Plan: Nothing changes
Reviewers: zmike, bu5hm4n, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7692
Differential Revision: https://phab.enlightenment.org/D7951
For now I made this EO-only but this definitely could be expose in
legacy API as well.
This simply gives exact information about the type of part, after doing
a recursive search. Edit Edit doesn't do a recursive search, only a
direct one, which can yield invalid results (eg. RECT or NONE instead of
TEXT in case of "elm.units.max" for a slider).
@feature
In Edje and Elementary, we have part objects, which are what is returned
by the interface efl_part(). Those objects can't be of an opaque type as
this doesn't work nicely with strongly typed languages such as C++ or
C#. In JS, Lua, C the types are weak and mostly runtime-based so it
doesn't matter much.
As a consequence, the documentation and the types need to look nice in
this EO API. Thus, we remove the abusive term "internal" and explicitly
call all those classes "part" something.
Eventually we want the types to be declared in the EO file so bindings
(C#, C++, ...) can generate the proper access methods, returning the
best possible types.
Note that right now a few of those part types are used in the legacy API
but don't actually need to be exposed externally.
This is kind of a mega commit that does all the renaming at once, but
it's really just a big sed operation. The power of good IDEs :)
Ref T5315
Ref T5306
Daniel Kolesa
Marcel Hollerbach
Xavi Artigas
Mike Blumenkrantz
Jean-Philippe Andre
Andy Williams