Summary:
This class is the same as efl_ui_text, efl_ui_text is editable by default.
This class should be removed
Reviewers: woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10831
Summary:
When the slider moves using step,
_drag_value_fetch(), _val_fetch() calculates a value from position of edje_part.
Then the calculated value is updated.
However, this causes a slight error.
This patch updates value first when moving with steps.
* Test Example
```
Evas_Object *sl = elm_slider_add(bx);
elm_slider_min_max_set(sl, -5, 5);
elm_slider_value_set(sl, 0.0);
elm_slider_step_set(sl, 0.1);
evas_object_size_hint_align_set(sl, EVAS_HINT_FILL, EVAS_HINT_FILL);
evas_object_size_hint_weight_set(sl, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
evas_object_smart_callback_add(sl, "changed", _change_cb, NULL);
```
```
void
_change_cb(void *data, Evas_Object *obj, void *event_info EINA_UNUSED)
{
double val = elm_slider_value_get(obj);
if (val == -5.0) printf("val[%f] == -5.0 \n", val);
if (val == -4.0) printf("val[%f] == -4.0 \n", val);
if (val == -3.0) printf("val[%f] == -3.0 \n", val);
if (val == -2.0) printf("val[%f] == -2.0 \n", val);
if (val == -1.0) printf("val[%f] == -1.0 \n", val);
if (val == 0.0) printf("val[%f] == 0.0 \n", val);
if (val == 1.0) printf("val[%f] == 1.0 \n", val);
if (val == 2.0) printf("val[%f] == 2.0 \n", val);
if (val == 3.0) printf("val[%f] == 3.0 \n", val);
if (val == 4.0) printf("val[%f] == 4.0 \n", val);
if (val == 5.0) printf("val[%f] == 5.0 \n", val);
}
```
If you move the slider using step in this test,
You can see that some logs are not visible. (Some values are incorrect)
Test Plan:
elementary_test -to slider
elementary_test -to efl.ui.slider
Reviewers: woohyun, cedric, bu5hm4n
Reviewed By: woohyun, bu5hm4n
Subscribers: bu5hm4n, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10662
Summary:
The internal and the API we would like is mostly a canvas API. A lot of the code
in evas is working around the fact that efl_input_device is not defined inside Evas.
This patch is the first step to try to clean this up.
Depends on D10487
Reviewers: zmike, raster, bu5hm4n, Hermet
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10488
these require legacy types and headers, which should not be brought into
this header
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10235
Summary:
this makes the meaning of the variable more clear
no functional changes
Depends on D10092
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10093
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
The idea of this widget is to provide to MVVM what Efl.Ui.Collection provide and
leverage the same shared logic for layout.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Co-authored-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9958
In an attempt to make things more complex than they should have been,
I tried to change the inheritance tree on the fly and assume widget would
rely on autodeleting its children. This is way more complex of a solution
than to let the View actually release all the child manually and just set
the window as the default parent.h
Co-authored-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9953
move more header includes around to fix building with Efl_Ui.h
ref T8228
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10022
this should include emotion, since that component is used internally,
and it should not explicitly include api headers which should be in
public headers
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9977
This started as a small commit, when pressing enter -> set the item as
selected.
However, it was a bit more complex, it seems that there was never config
update code to copy bindings into the user profile. Which lead to the
fact that you are missing a lot of keyboard related features if you
havnt wiped your config in the last 1-2 years. For me keybindings for
Efl.Ui.Scroller Tab_Bar Image_Zoomable (Item) have been missing and were
never inserted. WHich is a problem for a user just constantly updating.
For now i created a function that copies over the bindings from the
system config, and they are merged into the user config. Intentional
leaving our of keybinding structs for a user-config will result in them
beeing merged again on the next config update. If you want to get rid of
key bindings as a user you can just keep the empty struct, which is the
signal for "i know what i am doing, i do not want to have them". The
problem that the system config is partly invalidated (due to moving the
key bindings struct to the user config), is fixed due to the fact that
the config is reloaded after that.
This function should be called everytime someone updates the config in
regards of the keybindings.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9723
this changes image internals to use the more standardized group_calc method
of sizing and causes all previous operations on the image which would have
resulted in an immediate recalc to instead defer the calc until the
group_calc function is called
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9686
this should be efl_canvas_group_group_calculate to match eolian function
naming
no functional changes
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9685
walking here the parent chain can be very costly, esp. if you make a lot
of widgets visible or hide them. With this commit we ensure that we only
walk the parent chain when there is a custom chain, which is only the
case in legacy. This gets us about 2-3 FPS on the rpi with the
item_container benchmark.
With earlier commits, tree_unfocusable and disabled is honoring the
whole parent chain, so checking that alone, without the parent chain, is
fine.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9645
asking for a parent provider only makes sense if we are having a custom
focus parent provider, otherwise this will just result in the normal
parent relation. Not doing this safes us a lot of time that we spent for
nothing in the focus evalulation code.
The gengrid change is needed as the parent provider should be applied
after the constructor is called, otherwise there is no garantee that
shared_win_data is not NULL.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9643
this introduces a shared place to all widgets. The shared pointer is
allocated in the window, as the window outlifes every widget that is
part of it.
This struct will be later used for further optimizations like:
1. There are really heavy focus operations which are only needed for
gengrid/genlst, there is no point in executing them if there is no
gen**** added to the window object. So we can skip the custom
parent_provider logic that is only introduced for gengrid / genlist.
2. Legacy focus APIs must do list walks, which means, on every focus
operation we always have to walk the full list up to the parent, which
is annoying and slow, as we *most of the time* do not use legacy focus
API.
This list can be continued, the above two cases are fixed in the next
revisions.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9642
Summary:
this removes elm_layout_sizing_eval entirely from the implementation
hierarchy of any efl_ui-based widgets, ensuring that future code will
correctly use efl_canvas_group functionality
Depends on D9439
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8059
Differential Revision: https://phab.enlightenment.org/D9440
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:
this brings API that connects the theme to the object. This reduces the
amount of code that you need to write in order to develop a widget that
can be scrollable.
For now efl_ui_grid and efl_ui_scroller are replaced with it.
efl_ui_list / efl_ui_list_view are not handeled with this, as they will
be replaced with newer widgets.
Right now this is only avaiable in the C API. However, wrapping this
into a mixin should be easy.
Reviewers: zmike, segfaultxavi
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9245
This can be done with Efl.Ui.Active_View
Reviewed-by: Jaehyun Cho <jae_hyun.cho@samsung.com>
Differential Revision: https://phab.enlightenment.org/D8907
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
when a widget is marked internal, widgets can use that to behave in
certain ways. Box for example uses this to not alter the widget_parent
property anymore. Which is usefull for when boxes are used internally.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8736
This reverts commit 74c48f0296.
The commit is reverted because the commit implements features during
feature freeze period before release.
74c48f0296 will be restored after release.
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
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
this needs to include all the public headers as well as all the private
headers so that when it is included internally it correctly provides all
available function prototypes that are not static
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8228
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/D8209
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/D8152
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
Summary:
As the result of discussion in T7458,
we need to rename all efl_model based classes with efl_XXX_Model sequence.
I've run few vote for this, see V42, V43
few classes are totally renamed as our consideration of misnaming.
| Efl.Model_Loop | Efl.Loop_Model |
| Efl.Model_Item | Efl.Generic_Model |
| Efl.Model_Container | Efl.Container_Model |
| Efl.Model_Container_Item | Efl.Container_Model_Item |
| Efl.Model_Composite | Efl.Composite_Model |
| Efl.Model_Composite_Boolean | Efl.Boolean_Model |
| Efl.Model_Composite_Boolean_Chlidren | Efl.Boolean_Model_Item |
| Efl.Model_Composite_Selection | Efl.Select_Model |
| Efl.Model_Composite_Selection_Chlidren | Efl.Select_Model_Item |
| Efl.Model_View | Efl.View_Model |
| Eio.Model | Efl.Io.Model |
| Efl.Ui.Model_State | Efl.Ui.State_Model |
| Efl.Ui.Model_Size | Efl.Ui.Size_Model |
| Efl.Ui.Model_Exact | Efl.Ui.Exact_Model |
| Efl.Ui.Model_Average | Efl.Ui.Average_Model |
| Efl.Ui.Model_Homogeneous | Efl.Ui.Homogeneous_Model |
I worried about Efl.Io.Model changes, cause it is widely used,
but as I tested, there is no issue found yet.
Eldbus.Model also may can changed Efl.Dbus.Model,
but I cannot found any class who using Efl.Dbus namespace,
so I left it future work.
Test Plan:
Run the Make Test,
it works well except Efl test about selection.
there are class inheritance problem exist in select_model,
I reported it and will fix it in another patch.
Reviewers: cedric, felipealmeida, woohyun, Hermet
Reviewed By: cedric
Subscribers: lauromoura
Tags: #efl, #do_not_merge
Differential Revision: https://phab.enlightenment.org/D7533
This model enable View that require to compute the size of their item
to rely on its logic to store all items size independently. It has the
same interface as the Homogeneous and should be exchangeable for a View.
It provide an average total size at all time. It use Efl.Ui.Model_Exact
to do most of the work and is a good example on how to alter a Model
logic.
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7661
This model enable View that require to compute the size of their item
to rely on its logic to store all items size independently. It has the
same interface as the Homogeneous and should be exchangeable for a View.
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7660
This model enable View that require to compute the size of their item
to rely on its logic to have all items of the same size. It is the
equivalent of the Homogeneous behavior of Genlist, except that now this
behavior can be customized outside of the View logic itself.
Differential Revision: https://phab.enlightenment.org/D7659
This model enable View that require to compute the size of their items
to rely on an interface to provide the properties they need to get the object
size. This is the base class for all the sizing logic of the new List/Grid View.
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7658
Ali Alzyod
Bowon Ryu
Cedric Bail
Mike Blumenkrantz
Marcel Hollerbach
Taehyub Kim
Xavi Artigas
Jaehyun Cho
Vincent Torri
Jaeun Choi
Hosang Kim
SangHyeon Jade Lee
Carsten Haitzler