Summary:
1/2 year ago we have removed the automatic generation of legacy
headers. In this go we also removed the installation of legacy eo beta
APIs, as they definitly should not be used. However, there is the legacy
systray API which does not depend directly on eo. Apps could use this
before due to specifying the BETA define, now they only can call the
API, but cannot construct the object they need. This adds this back
under the beta tag, so those apps can continue working.
I am not sure myself if i like the commit or not, its a beta thing, why
should we fix it. However, Its quite a easy thing to add such a
constructor method for us, and enables app to continue working.
Reviewers: zmike, segfaultxavi
Reviewed By: zmike
Subscribers: jf_simon, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9757
this takes the current generated output from eolian for legacy code in
efl 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: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8203
This prevents legacy EO classes from being exposed through .eo.h headers
or .eo in share/eolian/includes. Also removes a slew of useless xxx_eo.h
intermediate headers.
Notes:
- elm_systray has no proper API: it's not clear if the EO API should be
released (in which case it needs to be renamed to efl_something) and
there is no legacy API to create a systray object.
- Some files have been placed in a "FIXME" section, as I believe they
are necessary within EO land, but at the same time still don't
conform to the interfaces (eg. name starts with elm_).
- elm_interface_scrollable is required by photocam. This means photocam
needs to be adapted to fit the EO scroller API (still to be
completed, I believe).
Bugs:
- This breaks most C++ examples. I KNOW. And I'm working on it.
Ref T5301