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
This reverts commit 546ff7bbba.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
Cedric BAIL
Jean-Philippe Andre
Tom Hacohen