- User Since
- Jul 17 2013, 7:07 PM (317 w, 6 d)
it is duplicated patch of D9601
I'll abandon my patch :)
Mon, Aug 19
- you mean the index id? I think for the range, integer id would be much easier to understand and use for the user, but mostly user have object handle not the integer id... but they can get the index of item easily. if we do not make our index_get poorly like O(n)... I think using integer id is more intuitive.
- I think we need to give common experience on that usage, like mobile multi select by click, desktop multi select by ctrl or drag, so it is profile dependencies then widgets.. I vote config.
- the case of how implement it will be different per widgets I think, like collection widget, they have all the items list, they could manually update the selection on items, but in the view, data should be updated on the model... I don't think we need helper class for this selection. but let's see how many widget want to selection and how many widget have common implements.
- seems good to me.
- I think that is select_always. mostly if I clicked selected item, it should be unselected, but in select_always mode, it remained selected state. but in multiselect, selected item should be unselected, so I think select_always is only for single selection..
seems almost same but I think user can be set a group or klass only as assuming style is default.
I'm not sure @cecric is okay with keeping cache data without model in listview.
also calculating item position in every calls could be inefficient if it calls frequently..
Tue, Aug 13
Hi. sorry for late answer.
Mon, Aug 12
I was requested this feature from the tizen developers several times but at that time we couldn't have enough time to fix it so reject the request but if we can do this, it will improve scrolling performance very well.
I think it need to be 3 buffer for this, one is in the viewport and others are for the top and bottom....
Thu, Aug 8
yes. we can go with current group index.
Wed, Aug 7
Seems valid fix to me.
should listen others opinion,
but I like this patch and it is exactly what I expected our selection interface should be.
Thu, Aug 1
but the who will be managing the data? view itself? or viewmodel should?
we have statesmodel in the elementary,
I'm not sure we have plan to use them.
Mon, Jul 29
@bu5hm4n yeah we don't have code to skipping it yet.
Sun, Jul 28
the reason it has sizing eval is there are some demands that skipping sizing eval such as homogeneous size in the list or grid..
if we already know the size, we could skipping restricted size calculation and set the size by it's container.
I didn't write the code for skipping case, and that is why you couldn't understand the existance.
Thu, Jul 25
Jul 22 2019
remove un-wanted fix.
Jul 21 2019
Jul 19 2019
@cedric @felipealmeida @bu5hm4n
as my understand, our efl_view_model or efl_ui_state_model need to take control some ui-related boolean states in the model data.
select/unselect (by interally adding select_model)
Yeah...that was ugly.
I prefer this collection naming,
but only concern is collectionView is used in other framework as actual collection shelf view.
yet I think it is doable name till we have other good candidate.
Jul 18 2019
as I tested in latest version.
what else do we need for this?
if it is ready for merge, please let us know.
Jul 15 2019
remove efl_ui_layout swallow part fix.
this will be udpated another patch.
fallback the efl_ui_list changes,
clean up efl_ui_item signal emit which is duplicated code.
add 'efl.extra' in layout part list.
I realize that this patch is totally wrong.
we do not need to send any signal to text or icon, cause layout already send visible/hidden signal on the text and content.
currently this is internal infrastructure.
I hope we separate the single select option and select mode,
Jul 12 2019
Jul 11 2019
well then we could think about another names,
itemBox, itemWidget, itemScroller(?) itemCollection, itemLayout, itemController...
but most of these also have same problem...
these selection is more releated with entry and clipbaord cnp feature,
so selection_type doesn't looks general.
I think mvvm is not stableyet and the list_view_item_event need to be changed by fallowing changes.
first of all,
layout need to be changed Efl.Ui.Item.
oh okay.. to get their parent, make sense.
although mr taehyup working on some abstract c# items which wrapping the efl.ui.item without edje layout... still it seems helpful.
if it only need to be called by the container... is there any reason that it need to be eo API?
hmm... I think the patch is aceeptable but don't know it need to be a public.
hmm so this is the way you want to say the container widget before it packed... interesting..
so what if user forcely change the container after packed?
shouldn't we call the unpack or something?
the patch looks correct fix.
Jul 10 2019
DO NOT MERGE
to stabilize the item and mvvm feature,
let's keep this patch in do not merge stand
and reactivate it later.
@bu5hm4n is this concept can effect your container idea?
oh, okay. I'll revise the patch.
Jul 9 2019
and in the case item-emitted callback,
factory provide the abstract way of adding event on the item in mvvm case,
we don't have any prototype for this,
so I might be earlier to be stabilized...
This class is renamed as
also it related with
I think this class is ready, but just need to be confirmed @cedric and @felipealmeida as it is good enough to using item_factory in mono binding.
I also agreed @cedric.
once we were talking about name change to "model_client" but view is more generic and acceptable.
Oh....... sorry I was totally misunderstood about your comment..
so want to merge the list and grid in one item_container,
so you want to using "theme" namespace instead of list or grid class.
sorry I skimmed through the comment.
we wasted a day.. my apologize.
hmm... I got your point
but as I see... that is too tricky.
as I mentioned, list can use efl_ui_item or efl_ui_list_item,
and it has different namespaces in the theme,
so container should take care of this different namespaces in theme_set.
Jul 8 2019
currently it is private data structure, and I think we might not need this structure anymore with the size model.
for the notice,
this patch is the first try of merge this two different style classes,
and not the complete one.
after this patch, I'll keep update the patch with better optimizations.
Jul 7 2019
Jun 28 2019
Jun 18 2019
As we discussed in voice call meeting,
Event abstraction on item can be the additional role of factory.
here my question is, if factory can abstract the event callback add,
what object should be passed as the result of this event? item object or widget object with index as event info?
Jun 17 2019
in MVVM case, as cedric pointed,
child of Efl.Model will be the invariable value for specific item,
but in view object, numeric index can be accessible.
May 29 2019
I've tested few cases that I worried about,
but looks okay with it.
thanks for the work :)
fix the example crash on text_set and icon content_set.
I think this patch is not ready to land yet,
as it get crashed on efl_ui_list_example_1.c.
please do not merge yet.
I change the place_holder to placeholder so is there no problem in the name,
I think it is ready to land.
remove unnecessary spaces.
remove diff of depends patch
fix place_holder to placeholder
yeah I was consider it as a single noun, "placeholder"... it is my mistake. I'll fix it :)
update example code.
update missing theme part name changes.
update patch with change part names,
Text_Default -> Text
Content_Icon -> Icon
Content_End -> Extra
Content_Placeholder -> Content.
May 28 2019
May 27 2019
May 26 2019
hmm I agreed basic idea of this patch....
one my concern is when item size need to be updated by text / content changes...
i'll do few test with this patch and review it again.
May 24 2019
hmmm I have one suggestion,
May 21 2019
May 19 2019
can you update status of this diff?