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.
Units now form an actual tree stored in their own hash. This will
later replace all global state of Eolian, by introducing a master
unit that you will pass around.
Listing it here without guards will break for builds without c# enabled.
It was actually taken care of a few lines below where it gets included
with the right guards. This one was just around by accident I think.