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
Summary: accessible name_get interface added, popup does not have default text.
What should be read for the name information should be define by popup.
Test Plan:
In atspi mode, when an AT-client such as screen-reader queries, it should return
as "Alert title(if present)/text(if present)"
Reviewers: kimcinoo
Subscribers: cedric, jpeg, govi, rajeshps
Differential Revision: https://phab.enlightenment.org/D5466
This will be used to replace the part translation API in Elm.Widget. It
should work for both parts and non-parts (ie. the main text of a button,
for instance).
For now I'm taking the following approach:
- All efl_text_set/get strings are untranslatable, i.e. get() returns
the visible string, set replaces and can not be translated.
- translatable_text_set/get needs to be used to enable automatic
translation, which in turns calls efl_text_set to modify the visible
string. Thus, translatable applications will have to use
efl_ui_translatable_text_set a lot more than efl_text_set, unless
they translate strings application-side.
Note that some other frameworks take a simpler approach equivalent to
calling efl_text_set() with an already translated text. This prevents
runtime language changes of the application, unless the application
handles them specifically.
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
Also prefix with widget.
I want to rename this as child rather than sub. It's inconsistent with
the other parent/child hierarchies. Anyway the various hierarchies are
confusing, so let's keep this name :)
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
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
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.
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
This reverts commit 8a988717e1.
It seems we can't actually inherit from class more than once and neither eo
nor eolian will complain about it. You will just get random weird behavior.
This patch should come back once we have made an interface of edje.
This reverts commit 57d77c9041.
We are in freeze right now and this is a new feature. Considering the access
API is still in beta I might have let this slip by but its does not even build
../../../src/tests/elementary/elm_test_popup.c:27:1: error: conflicting types for ‘elm_object_part_access_object_get’
START_TEST (elm_object_part_access_object_get)
^
In file included from ../../../src/lib/elementary/Elementary.h:240:0,
from ../../../src/tests/elementary/elm_test_popup.c:6:
../../../src/lib/elementary/elm_object.h:521:54: note: previous declaration of ‘elm_object_part_access_object_get’ was here
EAPI Evas_Object *elm_object_part_access_object_get(const Evas_Object *obj, const char *part);
^
../../../src/tests/elementary/elm_test_popup.c: In function ‘elm_object_part_access_object_get’:
../../../src/tests/elementary/elm_test_popup.c:39:47: warning: passing argument 1 of ‘elm_object_part_access_object_get’ makes integer from pointer without a cast [-Wint-conversion]
access = elm_object_part_access_object_get(popup, "access.title");
^
../../../src/tests/elementary/elm_test_popup.c:27:1: note: expected ‘int’ but argument is of type ‘Evas_Object * {aka struct _Eo_Opaque *}’
START_TEST (elm_object_part_access_object_get)
^
../../../src/tests/elementary/elm_test_popup.c:39:13: error: too many arguments to function ‘elm_object_part_access_object_get’
access = elm_object_part_access_object_get(popup, "access.title");
^
../../../src/tests/elementary/elm_test_popup.c:27:1: note: declared here
START_TEST (elm_object_part_access_object_get)
^
../../../src/tests/elementary/elm_test_popup.c:39:11: error: void value not ignored as it ought to be
access = elm_object_part_access_object_get(popup, "access.title");
^
Makefile:43996: recipe for target 'tests/elementary/tests_elementary_elm_suite-elm_test_popup.o' failed
make[5]: *** [tests/elementary/tests_elementary_elm_suite-elm_test_popup.o] Error 1
If you still want this in make sure it actually can compile the tests you added.
This lets me narrow down the remaining cases of pointers across the EFL.
The void pointers will later need to be reevaluated on per-case basis and
replaced appropriately where possible/feasible.
This touches Edje and also Elementary where part names are used.
This commit blew up in size since now all content part APIs
(get, set, unset) require to use Efl.Part instead.
This is a big refactoring commit, but no logic should
have been changed. Fingers crossed.
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
This removes Efl.Pack_Named which had a terrible name,
removes Elm.Container which should have been renamed
Efl.Ui.Container anyway, and introduces an interface
Efl.Container instead.
The hierarchy tree is now changed as objects don't inherit
from Efl.Container (it's an interface, not a regular class)
but only implement it. Obviously it is very easy to
reintroduce an Efl.Ui.Container parent class if we need it,
but I guess it should have some actual logic. It's basically
part of what Elm.Widget already does.
Some function names have been modified to look better in C
with the efl_content prefix.
@feature
This removes the conflicts between the different parents and also
indicates that this is to be used internally by widgets and should
not be confused with the normal user visible parent.
It is an internal attribute that should not be used by people
not implementing widgets. Marking it as protected signifies it
as such.
Summary:
Popup has the main layout to show popup view, but it is not resize object of popup.
As the result, we cannot emit the signal to the main layout when we want to change the state of the popup.
So, popup inherited a layout signal emit and redirect the signal to the main layout.
Test Plan:
1. add the custom signal in elm/popup/base/default layout
2. send the custom siganl in application code
Reviewers: woohyun, raster, cedric, Hermet, singh.amitesh
Reviewed By: singh.amitesh
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3852
Mike Blumenkrantz
Sungtaek Hong
Amitesh Singh
Marcel Hollerbach
Lukasz Stanislawski
Shilpa Singh
Marcel Hollerbach
Jean-Philippe Andre
Daniel Hirt
Jee-Yong Um
Daniel Kolesa
Stefan Schmidt
Tom Hacohen
Cedric Bail
Shinwoo Kim
Taehyub Kim