Summary:
For now, how to check whether a widget is legacy or not
is to check flags in private data or static flag, which is set
during elm_legacy_add.
If Efl.Ui.Legacy interface is added, it can be easilly checked
by efl_isa(obj, EFL_UI_LEGACY_INTERFACE)
Reviewers: woohyun, jpeg, cedric, Jaehyun_Cho
Subscribers: conr2d, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5748
This is also another protected and beta API. Meant to be overridden by
subclasses, but belongs to a still unstable API.
The difference between the internal legacy and the EO API is really bad.
Same as with activate (previous commit).
Ref T5363
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
Summary:
Item: state_set_get, name, actions api added
Widget: children_get api added.
Test Plan:
In Accessibility mode, on item tap, color name should be read out,
and if the color is a selected color, state also should be read out.
Reviewers: kimcinoo
Subscribers: cedric, jpeg, govi, rajeshps
Differential Revision: https://phab.enlightenment.org/D4934
Summary:
Elm.Widget.event_callback_add conflicts with Efl.Object.event_callback_add.
To solve this problem, "widget_" prefix is added to methods starting with
"event".
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4521
Summary:
colorselector focus ui is not moving for palette and components items.
now it is changed to focus each item of palette and components.
Test Plan:
1. build efl elementary with this patch
2. remove /home/{user}/.elementary
3. launch colorselector with elementary_test -to colorselector
4. move direction key
5. see the new focus ui
Reviewers: jpeg, raster, Hermet, woohyun, bu5hm4n, cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D4288
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Complex types (i.e. list, array, hash, accessor etc.) now do not require
pointers with them anymore (the pointer is implied) and the same goes for
class handles. Eolian now explicitly disallows creating pointers to these
as well. This is the first part of the work to remove pointers from Eolian
completely, with the goal of simplifying the DSL (higher level) and therefore
making it easier for bindings (as well as easier API usage).
@feature
Previously events used to use class name as a prefix and ignored eo_prefix
when specified. This is no longer the case. Events follow eo_prefix by default
now. In order to get around this for classes where this is undesirable, a new
field event_prefix was added which takes priority over eo_prefix. If neither
is specified, class name is used like previously.
@feature
Xavi Artigas
Mike Blumenkrantz
Sungtaek Hong
Amitesh Singh
Lukasz Stanislawski
Marcel Hollerbach
Jean-Philippe Andre
Shilpa Singh
Jee-Yong Um
Daniel Kolesa
Stefan Schmidt
Taehyub Kim
Tom Hacohen
Cedric BAIL