Summary:
this was duplicated for a number of widgets in slightly different ways,
so it can be unified as a private layout function to reduce maintenance
costs
Reviewers: Hermet, YOhoho, Jaehyun_Cho, jsuya
Reviewed By: jsuya
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11818
Summary:
When call elm_progressbar_add, theme_apply of layout is called and
_efl_ui_progressbar_legacy_efl_ui_widget_theme_apply is called.
Then it calls the signal emit for the icon.
this call is unnecessary.
Test Plan: N/A
Reviewers: Hermet, bowonryu, Jaehyun_Cho, YOhoho, zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11811
There was code in progressbar that parsed its own theme name, applied a
change, reassembed it, and set it again. However, when we simply stick
to the theme apply code path that we have in efl.ui.layout_base, we can
simply set the horizontal / vertical part to be the element, the rest is
the class. This safes a lot of code, additionally, the setting of the
spacer had to be moved to the theme_apply method, as this would not work
otherwise.
ref T8501
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11076
this only allows the default part to be gotten when running the unified
widget. A later widget can then be used to expose the second progressbar
part.
ref T8501
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11075
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
these are internal apis for managing part aliasing on the C side,
but they apply to efl_ui_layout and not elm_layout
no functional changes
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D10090
unified widgets should use unified api internally and also be more explicit
about which min size hint (restricted or user) is being set in order to improve
readability of code
when unified widgets also implement legacy wrappers, legacy api should be used
for the legacy objects
no functional changes
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9495
previous commit introduced new events to range_display. This commit
ensures correct emittation of those events.
ref T7895
Differential Revision: https://phab.enlightenment.org/D9372
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
Summary:
historically there have been two methods of calculating sizes in elm:
* elm_layout_sizing_eval
* evas_object_smart_calculate (now efl_canvas_group_calculate)
the former was used to set size hints on widgets, while the latter was
used to perform internal size calcs for the widget. for things to
work correctly, these functions had to be triggered in just the right
order at just the right time. many hard-to-fix bugs related to widget
sizing over the years have been the result of this split
this patch removes elm_layout_sizing_eval implementations so that all
widgets perform both internal size calcs and size hint setting all
in the same function, ensuring that these are always in sync
the result is that in the vast majority of cases, far fewer recalcs
happen for widgets, and they are quicker to achieve their final size
Depends on D9438
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9439
Summary:
elm_layout_sizing_eval is a legacy function which should not need to be called
on new widgets
Reviewers: segfaultxavi, bu5hm4n
Reviewed By: bu5hm4n
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9434
(1) Following commit did not care of efl_ui_format_string_get(set) of
elm_slider_part_indicator_eo.c
e776f5f Efl.Ui.Format revamp
Even though you call elm_slider_indicator_format_set with "%1.0f",
elm_slider_indicator_format_get returns NULL.
(2) The commit does not initialize format variables
- elm_slider_indicator_format_get
- elm_slider_unit_format_get
- elm_progressbar_unit_format_get
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9276
elm_progressbar_value_set with value bigger than max (or less than min) set to
max value instead of the bigger value. Following commit broke this behavior.
5efb4b3 efl_ui_*: get range users onto the same semantics
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9277
this commits introduces unified behaviour for the users of the range
interfaces. This includes:
- The same errors for limit_set errors
- The same errors for value setting outside the range
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9241
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:
some progressbar styles do not have certain parts, so it's necessary to
check part existence on theme load to avoid triggering unnecessary
errors
@fix
Depends on D8981
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8982
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
since commit a1addad60e, To add myself as a sub object of parent object will be
done in Efl.Ui.Widget constructor.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8280
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8144
Summary:
now that the error codes have been change to be compatible with eina_error,
this can be removed and will work through eina_error naturally
fix T7718
Depends on D8067
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Maniphest Tasks: T7718
Differential Revision: https://phab.enlightenment.org/D8068
Summary:
this swaps the values of "no error" and "error" in order to maintain
consistency with the rest of efl where the zero value means "no error"
Depends on D8060
Reviewers: cedric
Reviewed By: cedric
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8063
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
Summary:
Efl.Ui.Theme class is required to support language bindings.
Efl.Ui.Theme works based on current elm_theme features.
This patch fixes T7357.
Reviewers: segfaultxavi, cedric, lauromoura, woohyun, zmike, SanghyeonLee
Reviewed By: segfaultxavi, SanghyeonLee
Subscribers: SanghyeonLee, herdsman, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7357
Differential Revision: https://phab.enlightenment.org/D7244
Summary:
A call to efl_data_Scope_get is actually quite dangerous,
efl_data_scope_get will return a pointer to a 0 sized segment in memory,
this is happening based on how the class data is organized. So in theory
you could use this pointer and accidently write to it. This resolves
this issue.
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6337
This reverts commit 1b245787fe.
This is a workaround patch, even occurs a regression bug that
breaks widget signal emission logic. (Happened in Enventor toolbar)
I reviewed this code seriously and found out
ui_layout sub object unset logic has been changed.
Obviously that breaks the elm compatibility.
When sub-object of layout is removed, it tries to remove sub-object from
the layout internal list. Problem is, some widgets sends internal signals
when sub-object is removed(i.e "icon,hidden") , but layout returns the
valid object even though sub-object unset is called prior to signal,
means, "icon,visible" not "icon,hidden" emitted.
This logic obvisouly changed from the previous efl version.
And we need to fix that logic first.
See _efl_ui_button_legacy_efl_ui_widget_widget_sub_object_del()
to check this issue.
1. button: sub_object_del()
2. layout: sub_object_del() => sub object must be removed.
3. button: signal emit() => for updating states
4. layout: content_get() => returns valid object?????! (Issue)
Summary:
When _icon_signal_emit is called, "icon" part always exist. so, it only make
"visible" signal.
this fixes that issue
Test Plan:
elm_object_content_unset(button);
elm_object_content_unset(radio);
elm_object_content_unset(check);
elm_object_content_unset(progressbar);
Reviewers: Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6241
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: remove the elm legacy name of efl ui theme
Test Plan: run elementary_test and test efl ui widget cases
Reviewers: Jaehyun_Cho, woohyun, cedric, raster, jpeg
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5934
Summary: a segmentation fault occurs once the argument is not valid.
Test Plan: N/A
Reviewers: cedric, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5974
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
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
Mike Blumenkrantz
junsu choi
Mateusz Denys
Marcel Hollerbach
Shinwoo Kim
Xavi Artigas
Yeongjong Lee
WooHyun Jung
Jaehyun Cho
Hermet Park
Cedric BAIL
Taehyub Kim
Bowon Ryu
Daniel Kolesa
Carsten Haitzler
Sungtaek Hong