Summary:
pulse_mode is now implicit with pulse, if you set the progressbar to
pulse, the state is internally adjusted in a way that the theme is put
into the correct state. Legacy is not impacted by this because of the
previous commit.
ref T8501
Depends on D10941
Reviewers: cedric, woohyun, zmike, segfaultxavi
Reviewed By: zmike, segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8501
Differential Revision: https://phab.enlightenment.org/D10942
Eolian @properties should be documented at the property level, and
documentation at the setter or getter level should be left to setter-
or getter-specific comments. There is usually no need at all to have
setter- or getter- specific comments.
Also, a property is not a method so descriptions should match that.
This patch removes lots of duplicated text, and will allow enabling
by default the eolian check that ensures that properties have proper
property-level docs.
No functional changes.
we concluded min,reached and max,reached should be on every widget that
implements range_display. This here is the start of that work, the
events are moved, next commit fixes all widgets, the last commits
enables tests in the spec unit test.
ref T7897
ref T7895
Differential Revision: https://phab.enlightenment.org/D9371
This class helps widgets which contain a numerical value and must display it,
like Progressbar (units label), Spin, Spin_Button, Slider (both units and popup
labels, in legacy), Tags (when in shrunk mode) or Calendar (year_month label).
Previously this was a mix of interface and mixin: widgets had to support setting a
formatting func, and the mixin offered support for formatting strings, by setting
an internal formatting func. On top of that, the spinner widget supported "special
values", a list of values that should be shown as certain strings instead.
This has now been simplified and unified:
Widgets including this mixin can use the formatted_value_get() method which accepts
an Eina_Value and returns a string. Thats's it.
The mixin adds three properties to the widget (format_values, format_func and
format_string) which users can use to tailor formatting. The widget does not need
to know which method has been used, it just retrieves the resulting string.
This removes a lot of duplicated widget code, and adds functionality which was
missing before. For example, all widgets support passing a list of values now.
Widgets must implement the apply_formatted_value() method so they are notified
of changes in the format and they can redraw anything they need.
Tests have been added to the Elementary Spec suite for all cases.
Legacy widgets behavior has not been modified, although a few needed some code
changes.
Summary:
Add a property (show_progress_label) to allow controlling whether the progress
label displaying the exact progress is shown or not.
This was possible in Legacy but the functionality was lost in Unified.
Updated elementary_test to showcase this property, and also the other label
formatting options, which where not tested anywhere.
Added a simple progressbar unit test. It only checks that retrieved value is the
same as the set value, so it is more of a placeholder for future tests.
**This is needed by a future patch which will introduce more formatting options that clash with the current implementation.**
The presence of a formatting function was used to decide if the progress label was shown or not. This explicit property simplifies things.
Test Plan:
Everything builds and passes tests.
`elementary_test -to Efl.Ui.Progressbar` should show a few more bars with different formatting labels, and a checkbox to toggle rendering of one of them.
Reviewers: bu5hm4n, zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9202
Summary:
This clarifies a bit the whole Orientation vs. Direction confusion, at the
expense of longer names (Image_Orientation vs. Layout_Orientation).
Also, the interfaces are now adjectives (Orientable) and the enums have long
names (*_Orientation).
Pretty big patch, but no functional changes.
Relates to T7863
Test Plan:
Everything builds and passes tests.
Elementary_tests show same behavior, including the "inverted" widgets, which
are the only parts which received a bit of code changes.
Proof:
https://travis-ci.org/Enlightenment/efl/builds/536277282
Reviewers: zmike, bu5hm4n, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8946
Summary:
All legacy @since tags have already moved to the *.legacy.h files.
EO files are now devoid of @since tags (except some eldbus still
needed for legacy).
Upcoming patches will add @since 1.22 to those APIs which come out
of beta in this release.
APIs marked @beta do not need @since tags.
Test Plan: Everything builds, EO docs (like DocFX) have no Since tags.
Reviewers: zmike, bu5hm4n, lauromoura, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8430
Summary:
Instead of surrounding all the #include "*.eo.h" lines in Efl.h
with #ifdef EFL_BETA_API_SUPPORT, include these files unconditionally, but mark
all classes as @beta in the eo files.
This will allow taking them out of beta one by one as we deem them stable enough.
Otherwise, the current procedure involves moving the #include line out of the
ifdef block, which is cumbersome and messes include order.
Depends on D7950
Fixes T7692
Test Plan: Nothing changes
Reviewers: zmike, bu5hm4n, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7692
Differential Revision: https://phab.enlightenment.org/D7951
display contains properties that are used to manipulate the display.
Range_step is a interactive property since it manipulates the way the
user interacts with this widget. This resolves a few unimplemented APIs.
ref T5719
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7715
If we are to choose Efl.Ui.I18n for the internationalization support, the localization API
should be named accordingly L10n.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7507
Summary:
Efl.Ui.Layout namespace is removed to keep consistency with other
widgets.
Consequently, "Efl.Ui.Layout.Object" is renamed to "Efl.Ui.Layout" and
"Efl.Ui.Layout." is renamed to "Efl.Ui.Layout_".
Reviewers: segfaultxavi, bu5hm4n, cedric
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers, SanghyeonLee, woohyun
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7291
The interface efl_part_get should not be directly called from C, but the efl_part
wrapper should. It rely on efl_noref to properly destroy the object. Binding can
control the lifecycle of the reference the way they want by either calling the
wrapper or efl_part_get directly. It also means that the ugly ___efl_auto_unref_set
doesn't need to be exposed outside of EFL anymore.
Differential Revision: https://phab.enlightenment.org/D6098
Summary:
All events must have a type now, otherwise bindings don't know how to handle
the event_info field.
Most of the missing event types were actually "void" (no event_info present).
Some struct definitions had to be moved to eo instead of h files, so they
are available to bindings. Some have not, and are marked with FIXME.
Some namespaces have been fixed (like Efl_Event_Cb -> Efl.Event_Cb).
In general, there are hundreds of changed files, but mostly to add a type which
was not present before, so there's no harm done.
Also, A lot of FIXMEs have been added which should be, like, fixed.
For example, some events can send different types of event_info, which is
very inconvenient (and error prone).
Test Plan: make with c# bindings works, make check and make examples work too.
Reviewers: cedric, q66, lauromoura
Subscribers: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6169
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:
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
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.
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
Marcel Hollerbach
Xavi Artigas
Mike Blumenkrantz
Cedric BAIL
Yeongjong Lee
Jaehyun Cho
Cedric BAIL
Hermet Park
Amitesh Singh
Sungtaek Hong
Andy Williams
Lukasz Stanislawski
Marcel Hollerbach
Jean-Philippe Andre