eo methods should not be called on legacy objects
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8487
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/D8166
Summary:
This reverts commit b0a7c4b086.
This is adding another EFL bug to work around an EFL bug.
Reviewers: raster
Subscribers: devilhorns, stefan_schmidt, bu5hm4n, thiepha, cedric
Differential Revision: https://phab.enlightenment.org/D5933
or update with a small delay after any change and check mouse button
mask to avoid some bizarre mouse up event that is stopping the
selection form continuing with a mouse up event... so this works
around that and still works.
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 merges them with the now standard interface:
Efl.Canvas.Layout_Signal
Some wrapping work was required for legacy API which
takes no user_data in del() but instead returns it. The
new EO function, while harder to use, is more correct
(you can't delete the invalid callback by accident, and
this follows EO events design).
Another crazy wrapping was done in entry/text in order
to add the callbacks to 2 objects instead of just one,
and still return the user data.
As for Naviframe and Popup, those two widgets override
signal_emit to forward the call to another object than
the resize object, but not callback_add/del. So they
are definitely broken.
Ref T5315
Summary:
There is no way to allow/deny the text selection feature.
It is only controlled by disabled state. But, some UX does
not want to allow the text selection on editable entry widget.
@feature
Test Plan:
Run the following test case. You can see "Select Allow" check box.
elementary_test -to entry
Reviewers: tasn, herdsman, cedric, thiepha
Reviewed By: thiepha
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3934
Mike Blumenkrantz
Derek Foreman
Carsten Haitzler
Shinwoo Kim
Jean-Philippe Andre
Jihoon Kim
Tom Hacohen
Youngbok Shin
Cedric BAIL