- User Since
- Jul 17 2013, 7:07 PM (339 w, 4 d)
Wed, Jan 15
Do not merge yet as this implement need to be discussed in right way.
Sun, Jan 12
I think it would better to have only one way to get the event for user,
so they don't need to care about child or children,
so if it has to be changed,
Mon, Dec 30
remove smart check.
Tue, Dec 24
Mon, Dec 23
Sun, Dec 22
Dec 20 2019
One question about event stabilizing,
the class of efl_model is since 1.23
but these events beta and being stabilized in 1.24,
so do we have to put the @since tag on the event either?
Dec 19 2019
I'm not sure it can doable in app side level as _elm_widget_item_view_clear is elementary private function and all deletion process in genlist is also internal.
hmm need to think about the way of doing this again as application can intercept the deletion also...
I have one question regarding all composite model.
now everywhere we can see the unit for model,
and to change this, we should change all of them and I don't think it is doable thing as most of them are already stabilized.
I think it can be out of beta as index_range is already stabilized.
Dec 18 2019
thanks for fast fix :)
isn't multi_selectable_index_range also needed to changed uint64 ->unsigned int?
change item->eo_obj to eo_item.
Dec 17 2019
I have a question regarding this clickable part.
Dec 16 2019
Dec 15 2019
Dec 11 2019
no, I don't want to :) I'm just asking any possibility cause I hope it would not.
I think we got an agreement that most of mvvm infrastructure is firmed,
so I want to move forward :)
I'm more prefer to have abstract way to indicate the item as index can be changed by inputs,
but it's time to decide whether we go with int or not...
still int index is widely used for indicate the item in gui frameworks,
I think user fully understand that they need to tracking input changes to get the right item.
Dec 10 2019
are there any chance to change this class name or method?
Dec 9 2019
Nov 24 2019
Nov 19 2019
One big question regarding this header and footer is...
how we support horizontal header/footer.
Nov 18 2019
I'm thinking to adding more item styles,
Nov 17 2019
Nov 14 2019
I like the names.
after few reviewing on the class method, I think those two either can be stabilized :)
issue is resolved.
more right way of reverting it is revert elm/genlist: defer recalc when applying a name filter either
let's guess user want to make an item with progressbar in the center.
or some complicated layout like 3 line text and 3 different check and icon and button.
there are tons of different demands of making their list by their own gui,
we cannot support all of them.
Nov 13 2019
it only hold one swallow part which have the same size of item.
It is just single item container which make user customize their own item without using edc,
so yes, it could be default item if user make an horizontal box and pack the two icon and label. that is the example case I guess.
the idea is,
user may decide the size of item(or their content) by set the min size themselves,
and decorating item as it's own demands.
so the conclusion is we maintain current classes as what they are?
we spend too much time to find out best figure for this,
so I'm okay with current way as it is the conclusion of long discussion.
isn't it too overlapped with bar_mode set?
we already have EFL_UI_SCROLLBAR_MODE in both axis,
with a AUTO(means if content is bigger than viewport, scrollbar shows, if smaller then viewport, hidden), ON, and OFF.
Nov 12 2019
Nov 11 2019
- Default : I think Default is quite generally used in this case but standard also looks good.
- Placeholder : I like the Decorator (or Decoratable) as a name, though placeholder is more intuitive.
- Context : First of all we need to define what exactly this item will do. if it only works with flip(or slide) the item and give another options, Slidable or Hidden_Option can be used. I prefer to have more confirmed type of item not too general and can be understood in many ways.
Nov 6 2019
so is this some alternative way after removing select_always?
as I see the usage looks quite similar..
Nov 5 2019
I'm not tested every cases,
but it seems works as what we expected.
Nov 1 2019
wasn't it better to allow select_range for integer only,
so user can call for collection
Oct 31 2019
I was thinking we cannot do this in c either,
but yes, I forgot the existence of efl_part.
Oct 28 2019
so, at this moment,
- multi_selectable & multi_selectable_async to be out of @beta
- range_select range_unselect to be @beta till we find another usage of range.
@cedric you accept it so fast.
I tested all the patches in dev/zmike/genlist and confirmed it works very well in desktop test cases.
most of code that removed for optimization is exist for some issue cases,
but as time passed and all core frameworks are updated,
it would be great opportunity to confirm we really need this code or not.
but for Tizen,
I'm little bit afraid of applying this patch as their are so many un-expected usage and issues which wasn't really considered as issue on desktop environment.
thankfully we are only using upstream genlist in one profile which doesn't have that much usage, so I can find out issue more easily so it can be doable thing.
Oct 27 2019
ping? any plan for this?
Oct 25 2019
Oct 24 2019
Let's re-start discussion about this task and remove @beta asap.
Oct 18 2019
seems we could add del intercept for animation cases but then del_pre cannot do what we expected...
Oct 15 2019
Thanks for updating
Oct 10 2019
... ELM_OBJECT_SELECT_MODE_ALWAYS : This means that, even if selected, every click will make the selected callbacks be called. ...
code seems fine, but one question in inline.
Oct 9 2019
Sep 26 2019
oops. i'm late on this.
and for the notice,
me and @bu5hm4n agreed to keep multi_selectable and multi_selectable in beta,
while the selectable and single_selectale is stabilized.
hmm... I think boolean model is quite useful to userside, but still user can access boolean data by property get right?
if then it seems not serious problem in here,
at least we still have a moment to out of beta for this class in tizen side, only few weeks though.
can you land it before we release it?
if we not release door shutdown till tomorrow I can do that.
hmmm could be.
anyway we have change to make it public after released, so okay I agreed.
it has same problem iterator<ptr(uint64)> stable error.