The efl_ui_layout.eo.h header was incorrectly not included in
Elementary.h, which resulted in build failures after the legacy
and otherwise unused efl_ui_layout.eo.legacy.h include was removed.
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:
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
Summary:
Efl.Ui.Layout namespace is removed to keep consistency with other
widgets.
Consequently, "Efl.Ui.Layout.Object" is renamed to "Efl.Ui.Layout" and
"Efl.Ui.Layout." is renamed to "Efl.Ui.Layout_".
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers, SanghyeonLee, woohyun
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7291
Summary:
We've been missed type of class name.
Add legacy class name to maintain compatibility.
@fix
Reviewers: jpeg, woohyun, Jaehyun_Cho
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5749
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
usages.
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
Ref T5315
elm_layout_sizing_eval() marks an object as requiring recalc.
Unfortunately, it's been massively abused by various widgets into
actually doing the calc, or the min calc. So we end up with one API
that has 3 different definitions depending on the widget type:
1. Mark as requiring recalc (correct, respects doc, elm_layout)
2. Calculate min size and other size hints
3. Actually do some geometry modification
I believe we need to clarify these 3 requirements into 3 very clear
and specific APIs in elementary. Right now we have similar functions
in evas for 1 (evas_object_smart_changed) and 3 (smart_calculate).
But their exact definition also isn't necessarily what we want for
elementary.
Another clear problem is that layout_eval does not do any calculation
(in theory), so the "eval" word is a bit of a stretch here.
Once we're sure about the exact API we want, we can add this back to
EO and make it work across our EO widgets. For now let's just keep
the legacy API, and its EO overrides, as is.
Ref T5315
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
Here's the reasoning:
1. We will expose as many edje APIs as possible (and meaningful)
through the elm layout class.
2. Access to internal objects is usually risky, as it allows apps
to bypass EFL in some ways, leading to potentially undefined
behaviours.
3. If the need arises we can still add a similar API back to EO,
later.
Back to #1, it seems that the need for edje_get() was mostly to
call manual sizing functions, or the missing message_send(). I will
make sure these are accessible from the layout itself.
Ref T5315
This makes layout parts implement Efl.Ui.Cursor.
This also adds the missing bool returns from that interface.
This removes 7 APIs from Elm.Layout.
Ref T5315
This is an API enabling accessibility on text(block) parts
in a layout. But it is said to have many issues. I can already
see that it only changes a flag but doesn't trigger any code
to create the appropriate objects, so definitely not fully
working.
According to @kimcinoo this may remain in legacy land for now.
The expected usage is efl_text_set(efl_part(layout, part), text);
Same for text_get.
Also, added an example how to make API easier with providing
efl_text_set/get for the widget itself, in efl_ui_button. Please see
this example.
This reverts commit 584e17ae84.
After talking to @herdsman (before xmas) we concluded that we
didn't necessarily want a generic version of efl_text_set/get
for elm_layout. Instead, each widget that should have a default
text part should implement text_set/get themselves (very simple).
Note that Efl.Ui.Text somehow does not "implement" efl_text when
looking at the eolian files. It works by composition.
This implements support for efl_text_set() for the default
part (NULL). This also adds support for efl_text_set(efl_part())
for layouts. This should cover a LOT of widgets :)
The next step is to remove Elm.Layout.text but it's used in too
many places at the moment. @herdsman!!
if EFL_EO_API_SUPPORT is not defined in user side, this will break the build.
because Elm_Layout type is defined in eo header file.
Just keep using Evas_Object * in legacy yet.
This moves the part_box and part_table APIs to a fake object
like was done in Edje Object.
This also adds support a few new APIs to those containers,
so they behave exactly like Edje.Object.
This is another implementation bit of "eo_part".
Daniel Kolesa
Carsten Haitzler
Daniel Kolesa
Jaehyun Cho
Xavi Artigas
Woochan Lee
Pawel Aksiutowicz
Jean-Philippe Andre
Daniel Zaoui
Daniel Hirt
Andrii Kroitor
Hermet Park
Jee-Yong Um
Cedric BAIL