This change finally introduces deferred parsing of inherits to
Eolian, after a long time and many iterations. That means instead
of parsing inherits directly as part of the main file's parse pass,
they're pushed into a queue and parsed later. The validation engine
was modified to properly fill in the remaining info afterwards.
This may introduce breakages but I haven't noticed any. It also
properly unlocks cyclic dependency support in Eolian.
Additionally, this also introduces checks for duplicates in class
inherits (class Foo(Bar, Bar) is no longer possible) and it adds
stricter name checks, so you can no longer have a class Foo.Bar
and refer to it as Foo_Bar in implements. This was actually never
meant to be supported, but the check was previously broken.
@feature
Summary:
when Efl.Ui.Image has an image,
efl_file_set(efl_added, NULL, NULL) is not working.
I think this should remove prevous image and go back to empty image.
@fix
Reviewers: jpeg, cedric, eunue, woohyun, Jaehyun_Cho
Subscribers: Blackmole
Differential Revision: https://phab.enlightenment.org/D5742
The elm_layout_text_get is using efl_text_markup_get by following commit.
commit c07a40c745
elm: make elm_object_text_get return markup info as well.
This commit solves following issue
https://phab.enlightenment.org/T6642
If I set object text as below
elm_object_text_set(btn, "Some<br>text");
then elm_object_text_get(btn) returns "Some text" not "Some<br>text".
So using efl_text_markup_set makes sense.
better rely on the adapter and wait for realization so the adapter is
wether created or not even created but used with content. This fixes
item content focus, crashes at startup and a freeze in genlist test!
This commit solves following issue
https://phab.enlightenment.org/T6642
If I set object text as below
elm_object_text_set(btn, "Some<br>text");
then elm_object_text_get(btn) returns "Some text" not "Some<br>text".
Window constructor is hijacked by the finalize method, which messes up
the normal order of operations. As a result, the legacy type name for a
window object was "elm_widget" rather than "elm_win".
This fixes a crash in E (as it checks the legacy type name to verify an
object's type).
See D5748
Summary:
elm_entry.eo is not installed to system directory like
"/usr/local/share/eolian/include/elementary-1", and
eolian_gen tries to refer elm_entry.eo which results in failure.
Test Plan:
Create any eo class file which inherits Efl.Ui.Layout.
eolian_gen eo_file.eo
observe eolian_gen finishes
Reviewers: jpeg, herdsman, woohyun, Jaehyun_Cho, cedric
Subscribers: conr2d, id213sin, JongminLee
Differential Revision: https://phab.enlightenment.org/D5760
Summary:
efl_ui_focus_layer_enable_set(obj, EINA_FALSE) can be called before
registered_manager assigned
Test Plan:
1. EINA_LOG_LEVELS=eo:2 elementary_test -to menu
2. terminate the elemetary_test
3. check that there is no focus_manager warning about a call to NULL
Reviewers: bu5hm4n
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5759
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:
parent_get and smart_parent_get are called in parent_widget_get
this also remove the duplicated code
Reviewers: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5757
Summary:
"--with-elementary-base-dir" option was ignored by recent patches on elm_config.
The macro is being used in elm_theme. It should be syncronized.
The default value of the macro is ".elementary".
@fix
Test Plan: N/A
Reviewers: raster, cedric, jpeg
Reviewed By: jpeg
Differential Revision: https://phab.enlightenment.org/D5755
elementary_test -to genlist
-> LOTS of warnings, when creating the genlist, as the items aren't
ready yet. This just avoids the WRN as recalc will happen later anyway.
Following @taxi2se's recommendation. This is indeed a focus method, and
Widget already inherits from Focus.Object.
Ping @bu5hm4n who probably wants to adapt this further.
Ref T5363
This was proposed by Dave on the ML, I think it makes sense. Right now
the enum is just like the boolean, feature-wise, but it makes more sense
semantically (mode is not a bool) and allows for future extension (eg.
only apply orientation update for landscape vs. portrait modes).
There is absolutely zero testing for this in our existing codebase. Yay.
This interface has a simple 'create' method to create Efl.Canvas.Object
given a key.
This is used higher-up in Ui.Text in the next commit.
Ui text: add ability to set item factories
Added API to set an item factory object.
This is similar to the previous item providers (that worked with
callbacks).
You instantiate a factory object and set it on the Ui.Text object.
Each factory implements the "create" method from
Efl.Canvas.Text.Item_Factory.
This also includes 3 public factories (Image, Emoticon and Fallback):
- Image factory: creates images from added entries (key strings)
- Emoticon factory: creates emoticons by querying the theme
- Fallback: creates image, then falls back to emoticon
If no factory is set, then the fallback (internal) factory is used.
See the added "Ui.text Item Factory" test in elementary_test for an
example of usage.
@feature
No need to split: those two are used in all the same classes, since the
split between Orientation and Ui.Dir.
Note that the enum types remain in the main namespace.
It's not working. Just "fixing" the API for consistency.
Also, we're lacking a proper hint for "markup without images".
So I think EFL_SELECTION_FORMAT_MARKUP should be without images, while
EFL_SELECTION_FORMAT_MARKUP | EFL_SELECTION_FORMAT_IMAGE would allow
markup with images.
Ping @thiep.ha
Ref T5329
Override mode is not available in the unified api. That's because you
can't do it in Wayland.
I still think those types are stupid and should all die: Win subclasses
handle them for you. Odd types can't be used anyway.
Ref T5322
Unless it's implemented for Wayland as well, AND provides more
information than a NULL event_info, I see no point in this being an EO
event. Keep legacy as-is: a smart callback only.
Also, minor cleanups to the EO file.
Ref T5322
in the case where a connection was not actively rendering, there was nothing
which would trigger a display flush, leading to applications potentially
deadlocking
@fix