Summary: this widgets inherit from Layout. they can use same text_aliases of Layout.
Reviewers: Jaehyun_Cho, woohyun
Subscribers: herb, cedric
Differential Revision: https://phab.enlightenment.org/D5859
Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
Summary: see also 73f8b3b78f
Test Plan:
1. elementary_test -to progressbar
and elementary_test -to efl.ui.progressbar
2. check that icon and text are visible
Reviewers: cedric, woohyun, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5818
Summary:
efl_part macros are using each widget's internally defined
default_part_get() functions to get default part name.
This might potentially cause errors when future widgets
inherits the widget but not overriding Efl.Text.text and
Efl.Content.content.
Reviewers: jpeg, cedric, woohyun, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5797
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 fixes some of the warnings generated by calling functions on NULL
objects. One of the main remaining points is to avoid unwanted warnings
on non-existing parts.
Ref T6326
Coverity reports a resource leak here. According to eina_strbuf
documentation, the result of eina_strbuf_release should be
free'd when not needed anymore.
Fixes Coverity CID1383551
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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
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.
This will be used to solve issues around style_set:
if the widget is legacy or pure eo we may need to select a different
style. So in the constructor we need to know whether we are legacy or
eo. Note that calling style_set in finalize only is too late as we would
lose information such as efl_text_set() called inside efl_add().
In Pb, the legacy units_format_set's user callback uses value to
be 100*value (0.0 to 100.0) and legacy format_function_set uses
value of range "0.0 to 1.0". This was broken after my patch.
Lets keep this behaviour in legacy APIs.
In case of new EO APIs, the value will be always from 0.0 to 1.0
in both format_string() and format_cb callbacks.
Reasons:
- This API has been confused with the min size of the widget, resulting
in badly laid out applications.
- The EO API was not very nice (Range is about numbers, the Gfx size
hint in a part is really ugly).
While I understand the value of this API and how it can be used in
scalable applications, it is in fact not absolutely necessary.
Alternatively to that span size, the widget min size can already be
defined from the application side, or the widget can simply be expanded
to fill in its parent.
This can obviously be reinstated later if the need arises for EO. For
now, keep this feature as legacy-only.
This is VERY tricky.
For legacy, just create an internal class that has both. It's easier
this way. For parts that are handled by Layout directly, we know from
Edje which type to return.
For EO objects we should know from the part name which kind of part we
are dealing with:
- text (overridden by the widget)
- content (overridden by the widget)
- special (new efl_part based functions)
- generic (handled by Layout)
Note: Efl.Ui.Slider was handling "span size" on ALL parts. That's bad...
This is now limited to "span" only.
This means that ALL part handles inherit from the base part class
Efl.Ui.Widget.Part. Layout is the only exception where Efl.Part is
specially overridden.
This is a first step towards generic part APIs, including background in
all widgets.
In Edje and Elementary, we have part objects, which are what is returned
by the interface efl_part(). Those objects can't be of an opaque type as
this doesn't work nicely with strongly typed languages such as C++ or
C#. In JS, Lua, C the types are weak and mostly runtime-based so it
doesn't matter much.
As a consequence, the documentation and the types need to look nice in
this EO API. Thus, we remove the abusive term "internal" and explicitly
call all those classes "part" something.
Eventually we want the types to be declared in the EO file so bindings
(C#, C++, ...) can generate the proper access methods, returning the
best possible types.
Note that right now a few of those part types are used in the legacy API
but don't actually need to be exposed externally.
This is kind of a mega commit that does all the renaming at once, but
it's really just a big sed operation. The power of good IDEs :)
Ref T5315
Ref T5306
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
Amitesh Singh
YeongJong Lee
Carsten Haitzler
Sungtaek Hong
Jaehyun Cho
Jean-Philippe Andre
Cedric BAIL
Chris Michael
Lukasz Stanislawski
Lukasz Stanislawski
Marcel Hollerbach