Summary:
ELM_PART_OVERRIDE_PARTIAL replaces ELM_PART_OVERRIDE and
ELM_PART_OVERRIDE_ONLY_ALIASES.
The difference is ELM_PART_OVERRIDE_PARTIAL calls super
ELM_PART_IMPLEMENT when subclass of part is not needed.
Test Plan:
Run elementary_test, Part Background, background part is well set.
Run efl.ui.panes/efl.ui.flip, check content is well set.
Reviewers: jpeg, Jaehyun_Cho, woohyun
Reviewed By: Jaehyun_Cho
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5566
Summary:
efl_ui_popup parts overrides efl_content and efl_text
which are sometimes not needed.
Test Plan: Run elementary_test -> efl_ui_popup tests
Reviewers: jpeg, cedric, woohyun, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: Jaehyun_Cho, Blackmole, herb
Differential Revision: https://phab.enlightenment.org/D5556
When a widget inherits layout in tries to set theme in group_add or in
constructor. When another widget inherits the previous widget, it sets
layout again with new klass name. This sets klass in the widget and
sets layout in super class, so that it can set layout only once.
Test Plan: Run efl_ui_widget related elementary test.
Reviewers: jpeg, cedric, woohyun, singh.amitesh
Differential Revision: https://phab.enlightenment.org/D5473
new eo widgets(efl_ui_ prefix) finds new edc group in
data/elementary/themes/edc/efl/*.edc.
New group name is "klass/group:style" and "base" group name and
"default" style name can be omitted.
for now, separator for style is ':' but needs to be decided.
theme_klass: set/get klass name used for resize_obj
theme_element: set/get group name used for resize_obj
theme_style: set/get style name used for resize_obj
element_update: automatically sets and apply theme for
sub object of widget.
Summary:
Unit is now stored in klass_def, parameter_def and function_def for
future calls to the Eolian API.
Reviewers: felipealmeida, jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5613
Summary:
eolian_cxx was segfaulting due to a null unit being passed to
class_get_by_file.
Reviewers: felipealmeida, jpeg, q66
Differential Revision: https://phab.enlightenment.org/D5611
The EFL_ACCESS_WINDOW_INTERFACE was used to check if an object is window.
This could make sense. But it would be better to use EFL_UI_WIN_CLASS for
consistency.
A window is using ecore_evas geometry value for its evas_object geometry value.
The evas_output_viewport x(y) value which is used in _elm_widget_onscreen_is
is always 0. So _elm_widget_onscreen_is could return EINA_FALSE, if ecore_evas
geometry x(y) value is bigger than 0, even though a window object is on screen.
So it is not correct to compare ecore_output_viewport and evas_object geometry
for a window object. Moreover it does not make sense.