Page MenuHomePhabricator

efl.ui.multi_selectable
Open, TODOPublic

Description

|interface Efl.Ui.Multi_Selectable @beta
|├ (P) select_mode
|├ (M) selected_items_get
|├ (M) select_range
|├ (M) unselect_range
|├ (M) select_all
|├ (M) unselect_all
bu5hm4n created this task.May 3 2019, 11:29 AM
bu5hm4n triaged this task as TODO priority.
zmike moved this task from Backlog to Evaluating on the efl: api board.Aug 30 2019, 11:11 AM
zmike added a comment.Sep 2 2019, 5:51 AM

This is an important item. What's going on here?

need to change namespaces.

Efl.Ui.Selectable / Efl.Ui.Single_Selectable / Efl.Ui.Multi_Selectable,

all of them have different namespaces and name-prefix of APIs,
we need to unify this names in one common things.

the candidates could be,
"efl_ui"
"efl_ui_selectable"
"efl_ui_entity"

select model is also reimplement this class, so not sure "entity", "object" or "widget" is good approach or not.

How about using the Selectable namespace and separate items from containers more clearly:

  • Efl.Ui.Selectable.Item
  • Efl.Ui.Selectable.Single_Container
  • Efl.Ui.Selectable.Multi_Container

I prefer Object over Item, not only Items can be selectable.

there are some cases that widget individaully selectable. like checkbox. so I also prefer "object" rather than "item" for this.
my personal preference is just Efl.Ui.Selectable stayed as interaface name. so simply object who are implement Efl.Ui.Selectable, can be selectable.
about single and multi, adding new namespaces Child_Selectable or Item_Selectable to distinguish selectable. Item_Selectable is good as it used most item conainter, but if you not prefer using "item" "child" or "children" could be an option. I don't know which one is natural, singular or plural. @segfaultxavi can make decision :)

ClassPrefix
Efl.Ui.Selectableefl_ui
Efl.Ui.Item_Selectable.Singleefl_ui_item
Efl.Ui.Item_Selectable.Multiefl_ui_item

@cedric introduce multi_async class on D9957, which accept index instead of selectable instance,

it seems single also need async class and name can be changed
Efl.Ui.Index_Selectable.Single
Efl.Ui.Index_Selectable.Multi

or

Efl.Ui.Item_Selectable.Single_Entity
Efl.Ui.Item_Selecatble.Multi_Entity
Efl.UI.Item_Selectable.Single_Index
Efl.Ui.Item_Selectable.Multi_Index

how about it?

I think i still prefer to have those 3 interfaces in one namespace.
I do not see a purpose in Single_Asny, as the single stuff can just be kept arround, that should not make the mem usage worse.
The Multi_Async interface can just be also in the Efl.Ui.Selectable. namespace.

I am also kind of confused, you are saying you are prefering object over item, but your class names are prefixed with item.

SanghyeonLee added a comment.EditedTue, Sep 17, 2:31 AM

I think i still prefer to have those 3 interfaces in one namespace.
I do not see a purpose in Single_Asny, as the single stuff can just be kept arround, that should not make the mem usage worse.
The Multi_Async interface can just be also in the Efl.Ui.Selectable. namespace.

I am also kind of confused, you are saying you are prefering object over item, but your class names are prefixed with item.

I prefer object than item in the name of Efl.Ui.Selectable, because Efl.Ui.Selectable can be used non-item class like checkbox.
I using item in Item_Selectable, as this Item_Selectable is only used in item_container. but we have select_model and we do not call item on the model, so "child" can be proper option than item..

the reason I want to keep Efl.Ui.Seletable as its own interface name not namespace is the unity of our interface names such as, clickable, observable, orientable, scrollable, zoomable, editable, playable.
if we change it Efl.Ui.Selectable.xxx,
scrollable also need to be Efl.Ui.Scrollable.Interactive, Efl.Ui.Scrollable.Manager Efl.Ui.Scrollable.Unit...

The difference to most of those interfaces is that the selectable stuff is consisting out of 3 interfaces (Efl.Ui.Selectable, Efl.Ui.Single_Selectable, Efl.Ui.Multi_Selectable). Clickable, Zoomable, Editable, Playable is only consisting of 1. And Scrollable indeed should change Namespaces IMO. In general I do not want to have those 3 in different namespaces as they belong together.
Also: Efl.Ui.Radio_Group uses Efl.Ui.Single_Selectable, so its not only item here ...

All in all: I would still prefer to keep the Interfaces in one single Namespace, the rule we apply here for naming, can also just be applied to Scrollable.

SanghyeonLee added a comment.EditedTue, Sep 17, 3:38 AM

I still think that *able interfaces are common definition of some features that self object can doable.
in that perspective,
selectable is "self" can be selectable,
item(child)_selectable is "self" can select my child
so fit in the definition.

I wondered how other frameworks define it,
but as I see,
QT only have selectModel and define container level selection only.
Android have checkable interface for self selection,
but no contianer selectable interface, and they have adapterView selection.
IOS have selectable property and selectrange on collectionview but they doesn't seems like any interfaces.

It is the preference between using namespace and unity of *able interfaces.
so I hand over the ball to you :)
if i have to pick the term between "entity" vs "object",
entity is my personal choice as it is generally used in new efl classes.

by the way,
it may not proper to mention it here,
but as we talk about selection,
what do you think about https://english.stackexchange.com/questions/18465/unselect-or-deselect this?
seems deselect is more often used than unselect.

Can we for now stay with the namespace topic ? Because right now i do not understand what you are proposing, what should be the new namespace ?

zmike added a comment.Tue, Sep 17, 5:33 AM

Can we for now stay with the namespace topic ? Because right now i do not understand what you are proposing, what should be the new namespace ?

The idea here is that any namespace which ends in able (e.g., selectable) defines a feature which is used on the "self" object, i.e., you pass an object and the feature applies to that object. If the namespace is item/child_selectable, however, then you would pass the parent and the feature would apply to the child.

We should discuss unselect vs deselect.

@zmike thank you for nice summary!

my personal opinion is well explained by @zmike,

but as I look into other frameworks,
no one define both interfaces of self selection and child selection,
so we can go anyways.

if selectable is namespace, scrollable need to be namespaces as like you said.

I agree Efl.Ui.Selectable is similar to Clickable, Scrollable or Playable, so it is OK in its current place.
However, I see not much benefit in creating a namespace to hold only two interfaces, plus we'll need to do the same with other interfaces.
Therefore, I would leave things in the place they are now.

Regarding unselect vs. deselect, in that link from @SanghyeonLee it says deselect is the most common word, except in IT, where unselect is the winner.
Therefore, I would not change it.

So we now decided to do nothing, is this looking fine now or not ?

There's still one last issue that has been discussed somewhere else... Z153#4024
How about we rename the methods so the verb is at the end: all_select, all_unselect, range_select, range_unselect,...
Sounds weird, but is consistent with Efl.Access.Selection.

(BTW, we used deselect there, damn)

so,

  1. Efl.Ui.Selectable stay as it's name.
  1. Efl.Ui.Single_Selectable Efl.Ui.Mutli_Selectable - no namespaces for this two. my idea for the name then, Efl.Ui.Group_Selection Efl.Ui.Multi_Group_Selection both name prefix is just efl_ui_select or efl_ui_group_selection. but current name is not that bad, name prefix need to unified.

    @cedric about async, are we only need multi select async? aren't single selection need to be controlled by index? if we can have single async, i would like to name them index_selection instead of group_selection, so there will be Efl.Index_Selection Efl.Multi_Index_Selection
  1. Range_Select/Range_Unselect to @beta as our discussion on MVVM chat room, Range can be changed with using Eina.Range in the future.
  1. Verb and Noun : yeah it seems better to change it. we need to distinguish noun/adj and verb clearly, so I think select mode also need to changed seleciton_mode or selectable_mode.
  1. unselect / deselect. we need to go one term for this. what is more general in other uifw? ios: https://developer.apple.com/search/?q=deselect https://developer.apple.com/search/?q=unselect pooply they have both but deselect seems more general. android : https://developer.android.com/s/results?q=deselect https://developer.android.com/s/results?q=unselect they use both word on doc but in public API they only control it by boolean value. qt : https://doc.qt.io/qt-5/qlineedit.html#setSelection https://doc.qt.io/qt-5/qabstractitemview.html using both word. but as an API, they have deselect, and deselectAll. xamarine : https://docs.microsoft.com/ko-kr/dotnet/api/?view=xamarin-forms&term=unselect only unselect used. gtk: https://developer.gnome.org/search?q=deselect https://developer.gnome.org/search?q=unselect messy like qt, uisng both word in docs and API name..

seems deselect is more general but we can find unselect usage also. I think both word user can understand easily so any of choice will be fine.

  1. select_single_only. we remove this option in select_mode,

    and now I think the only reason this was exist in select_mode before is for supporting remaining at-least-one-selection like radio button, so how about combine this feature in seleciton_fallback? the usage of selection_fallback is match with this select_single_only mode. are you agreed?
  1. Efl.Ui.Single_Selectable Efl.Ui.Mutli_Selectable - no namespaces for this two. my idea for the name then, Efl.Ui.Group_Selection Efl.Ui.Multi_Group_Selection both name prefix is just efl_ui_select or efl_ui_group_selection. but current name is not that bad, name prefix need to unified.

Sounds ok to me, but I am terrible at naming. So do not mind my opinion on this to much.

@cedric  about async, are we only need multi select async? aren't single selection need to be controlled by index?
if we can have single async, i would like to name them index_selection instead of group_selection,
so there will be
Efl.Index_Selection
Efl.Multi_Index_Selection

Current API of single selectable is ok from CollectionView perspective as we always need to keep a reference to the last selected object internally. Basically, I don't think we need any change in it for anything in CollectionView. Renaming to MultiIndexSelection is an idea, but I am not sure it will be good. I want to add at some point an API, like in Efl.Io that triggers callback to give you the selection in an Async way. Right now the API isn't doing that and so the name is not reflecting much of the intent.

  1. Range_Select/Range_Unselect to @beta as our discussion on MVVM chat room, Range can be changed with using Eina.Range in the future.

I think that at this point the entire MVVM infrastructure is going to stay @beta as the release is like tomorrow or some time later this week.

SanghyeonLee added a comment.EditedMon, Sep 23, 7:24 PM

hmm... MVVM was delayed quite long period and every one is waiting for using it now...
so in our expectation, at least basic infrastructure for making list and stable features need to be introduced in this release.

@SanghyeonLee, regarding new names for single/multi_selectable:
I think "selectable" looks weird for the containers. How about we use "selection" instead? In this way, the containers and the selectable objects inside are easily differentiated: Efl.Ui.Single_Selection and Efl.Ui.Multi_Selection.
Or if you want to have the same prefix for both: Efl.Ui.Selection_Single and Efl.Ui.Selection_Multi.

my suggestion was at the second,

  1. Efl.Ui.Group_Selection Efl.Ui.Multi_Group_Selection both name prefix is just efl_ui_select or efl_ui_group_selection.

and for the async, Efl.Multi_Index_Selection

so I also agree selection is better than selectable for container.
I added group and index prefixes but if it is weird it is okay to remove it.
and ... single... do we need single and multi both name? I was thinking that we could remove one in their name as they are default mode,
but not sure which one is correct.

I think Single_Selection and Multi_Selection also good enough :)

@segfaultxavi one question.
if we go selection, is it okay that we already have efl_ui_selection for text selection? isn't it need to be efl_ui_text_selection?

Efl.Ui.Selectable : stay
Efl.Ui.Selection : ??
Efl.Ui.Single_Selectable : Efl.Ui.Single_Selection? or Efl.Ui.Group_Selection or Efl.Ui.Group_Single_Selection
Efl.Ui.Multi_Selectable : Efl.Ui.Multi_Selection? or Efl.Ui.Group_Multi_Selection
Efl.UI.Multi_Selectable_Async : Efl_Ui_Multi_Selection_Async or Efl.Ui.Index_Multi_Selection?

I would try to leave out Group as much as possible from the name, as Group is logically somehow orthogonal to Single ...

one suggestion about select_all / unselect_all

what about making it property not method
so when chlidren is selected/unselected all, user can trigger boolean value in getter of select_all / unselect_all?

if it is right way, we should make select_all also in beta though.

if it is not change select_all to all_select and unselect_all to all_unselect.

I would try to leave out Group as much as possible from the name, as Group is logically somehow orthogonal to Single ...

yes that is what I worried.
okay than the name is being

Efl.Ui.Single_Selection
Efl.Ui.Multi_Selection

and prefix would be "efl_ui"?
but isn't that confusing Efl.Ui.Selectable Efl.Ui.Selection Efl.Ui.Single_Selection and Efl.Ui.Multi_Selection?

what about unselect / deselect? we go for current one?
access using deselect, that is one worry that going unselect.

sorry for spamming reply,

but if we plan to put beta on range_select/unselect, and it will use Eina.Range after all,

and if our iterator can have variety value (via Eina_Value?),
there are no reason we have both class multi_selection and multi_selection_aync?

range_select on this interface here uses objects, not ids. sp Range does not apply. For simplicitly of the multi_selection i would keep the iterator as its right now.

In regards of names: I find it quite confusing that we have Efl.Ui.Selection Efl.Ui.Selectable Efl.Ui.Single_Selection & Efl.Ui.Multi_Selection, can we keep the names as we have them right now ?

SanghyeonLee added a comment.EditedWed, Sep 25, 3:35 AM

oh that is the changed "Selectable" to "Selection" on Single and Multi actually.
but we should talk about prefix also.

now
efl_ui_selectable have event_prefix :
efl_ui so event name will be
event : EFL_UI_EVENTE_SELECTED
but c prefix is not in there so
capi : efl_ui_selectable_selected_set

efl_ui_single_selection has no prefix so
capi : efl_ui_single_selection_last_selected_get //why no set? if range_select is @beta we need to provide the way to set at least one item. I think we need select_set in here.
event : EFL_UI_SINGLE_SELECTION_EVENT_SELECTION_CHANGED

efl_ui_multi_selection has c_prefix so
capi : efl_ui_all_select
event : none

efl_ui_multi_selection_aync has nothing
capi : efl_ui_multi_selection_aync_all_select
event : none

this is real problem as I see.

If you want to select a item, do `efl_ui_selectable_selected_set(obj, EINA_TRUE); there is no reason for a API on the contianer for that.

So the last issue you are seeing here is that efl_ui_multi_selection hash a c_prefix and we should remove that ?

and single selection event name maybe?

one opinion for this is make of them have prefix of
efl_ui_object or efl_ui_entity or efl_ui_widget

efl_ui_object_selected_set
efl_ui_object_last_selected_get
efl_ui_object_all_select

like this.

or
efl_ui_selectable_selected_set
efl_ui_selection_last_selected_get
efl_ui_selection_all_select

selectable stay's current name and single and multi selection use "selection"

and... what about event name?
EFL_UI_EVENT_SELECT_CHANGED looks fine
but
EFL_UI_SINGLE_SELECTION_EVENT_SELECTION_CHANGED
looks not good..

EFL_UI_SELECTION_EVENT_SELECTION_CHANGED
or
EFL_UI_EVENT_SELECTION_CHANGED

but this may be confused by
EFL_UI_SELECTION_EVENT_WM_SELECTION_CHANGED
in efl_ui_selection

SanghyeonLee added a comment.EditedWed, Sep 25, 9:56 PM

if we go
clickable
&
item_clickable,

isn't it also go with
selectable
item_selectable
?

only matter is this single_selectable can be used in radio or model which is non-item group.

Okay we are spinning here in cycles. We cannot use item in the name, since selectable also applies to radio, which is not an item. In the same way we have said above that selection does not work because it's the same as we used with text.

sorry for spping :p
okay than... stay current name I'll drop the patch
now only matter we take care is prefixes.

Okay, how about removing the c_prefix of Efl.Ui.Multi_Selectable, and just fix the API calls ? (I can do that later on)

actually I think it would better to both of single_selectable and multi_selectable have common API,
like "efl_ui_selectable". is it strange? if it is strange then.. just make them be their own name is okay.

and...
event name,
EFL_UI_SINGLE_SELECTABLE_EVENT_SELECTION_CHANGED
is good?

lets make final stamp

Okay i am adding c_prefix: efl_ui_selectable; to single_selectable and Multi_Selectable. Revision will come in a few.

after discussion on D10184 we decide to mark multi_selectable and multi_selectable_async as @beta for this release.

multi_selection feature will be beta supporting till next release,
and we need to discuss about this class and names in detail further.

SanghyeonLee reopened this task as Open.Thu, Sep 26, 4:16 AM

reopen task as we decide to mark it beta in this release version.