Summary:
There are usecases where items should not be unselectable by the user.
For example in the tab_bar. With this commit, a tab bar user cannot
unselect a item by hand anymore.
Depends on D10305
Reviewers: zmike, woohyun, segfaultxavi, cedric
Reviewed By: zmike, segfaultxavi, cedric
Subscribers: SanghyeonLee, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10306
the problem here is that when we are using the signals from the object,
then the edje object itself will receive press/unpress events before
any content that is swallowed into the edje object.
This means, that no clickable content, added to a item could be clicked
without selecting / unselecting the item. Which was a problem.
With this commit the theme is sending signals which are then passed to
the efl.input.clickable mixin, this way, the part is stacked below the
added content, which means, clickable content will not select / unselect
the item anymore.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10892
this commit merges common functions from efl_ui_multi_selectable and
efl_ui_multi_selectable_async. Additionally, the two different aspects
of accessing the elements in a multi_selectable widget (numerical or
object based) are now abstracted into interfaces called range_numeric and
range_object. numeric APIs are also prefixed with id's, so its possible
for one widget to implement both (if there will ever be the demand to do
that in future).
The main reason for this split is:
- there is no good common path between mvvm based multi_selectable and
object based multi_Selectable, so there is no way that both sides would
benefit, without the other one suffering.
- If we find later on the demand to implement both on one widget, we now
can fully do that
- Common API is available for both types, so its less API and less
confusion for the API user.
ref T7871
ref T8265
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10675
Summary:
with this commit that api for single and multi selectable shares the
same prefix, which makes sense in c as we do not really differ between
those two types there anyway.
ref T7871
Reviewers: SanghyeonLee, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7871
Differential Revision: https://phab.enlightenment.org/D10183
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
For most event it is actually meaningful to share them with Efl.Ui.Collection_View so let's do it.
Differential Revision: https://phab.enlightenment.org/D9956
this should get a better solution later on. There is also no real usage
for that.
ref T7922
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9985
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
there are cases where the container does only implement single
selection, when then just asume implicitly single mode here.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9722
this brings a group item in the style of genlist / gengrid group items.
The group item theme does currently not provide the signals in the theme
that would be needed for selecting it. This is kind of intended, but we
might need API to express that.
ref T8115
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9583
these parts are hard copies of the part implementations given from the
layouts. Replacing them with the layout implementation just works
ref T8115
Differential Revision: https://phab.enlightenment.org/D9582
with this commit events are emitted correctly, even if the container is
already on the way to deletion. Additionally, the codepath that is
triggered when the item is selected via clickable is now also going
through the selected property.
ref 7905
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9517
right now they are just thin wrappers from what have been in
efl_ui_collection. This is just a first effort, the interfaces have to
be equipped with more and better API, more events, and tests.
ref T8057
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9515
this is meant to be implemented by entities that *can* be selectabled
(not to be confused with containers that can have selected contents)!
ref T8057
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9503
efl_ui_clickable_util was only for efl_input_clickable interface,
but there can be more cases which want to connect object event
to specific action interfaces (such as scrolling) in the future.
For that extension, efl_ui_action_connector seems better.
ref: T7847
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9486
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
this adds the mixin to the item. With this commit every class inheriting
from Efl.Ui.Item will automatically emit all the clickable events.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8830
Summary:
there is no reason to have this field, pd of a item is always passed
with the object.
Reviewers: segfaultxavi, zmike, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9423
efl_layout_signal is being overrided by efl_ui_layout,
so do not call the signal emit on resize object directly,
call the signal emit on the item widget.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D9233
there was this internal pointer to select_mode for getting the selection
mode of the container. However, we now have API for checking this, so
there is exactly 0 reason for doing this like this. Additionally, with
the old way of doing, bildings like C# or lua are just lost, they cannot
use this class at all in there implementations, as they cannot access
the privat data.
ref T905
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9263
this commit ensures that there is a public way of setting the container
to a item. This was also like this before, just with the difference that
it was set and unset in all privacy, however, we want to have this class
also ready for bindings, so we should stop making things privat like
this.
Note: the removed fields from grid and list have not been used.
ref T7905
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9262
Summary:
Most of item-based class will have similar efl.part such as text, icon, end.
creating this efl part per each class will be very hard to maintaining the class
and unnecessary eo generation.
so combine them in efl.parts of efl_ui_item.
sub item classes can use this efl.part by declairing ther own eo definition.
Reviewers: cedric, Jaehyun_Cho, segfaultxavi, eagleeye
Reviewed By: cedric, eagleeye
Subscribers: herb, woohyun, q66, lauromoura, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8582
Summary:
this was conflicting with a model event. Prefixing it with "item,"
resolves this, and describes better what it does.
Depends on D8413
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8414
Summary:
This reverts commit f629f11bed.
This breaks legacy events. As the selected event is used in legacy
widgets. Also this commits mixed up two different concepts, selection in
a entry etc. and selection of a item.
Depends on D8411
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8412
this takes the current generated output from eolian for legacy code in
evas 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/D8120
Summary:
Unlikely efl.ui.Layout, Item need to be focusable,
so it may traverse list by your command of focus moving.
Test Plan:
tested in
efl_ui_list_example_1.c
efl_ui_grid_example_1.c
check whether item show their focus properly.
scroll feature is not yet supported by efl_ui_scroll itself.
Reviewers: eagleeye, cedric, Hermet, felipealmeida, bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7465
Summary:
most usage of simple list, items are very limited and loading performance is not serious.
to support those requirement, this efl.ui.list will create scrollable box with efl.pack.
user can create list by packing an pre-loaded item object, Efl.Ui.List.Item class.
Test Plan: tested in efl_ui_list_example_1.c in examples.
Reviewers: cedric, felipealmeida
Subscribers: woohyun, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5861
Marcel Hollerbach
Cedric BAIL
WooHyun Jung
Mike Blumenkrantz
SangHyeon Jade Lee