- User Since
- Jul 17 2013, 7:07 PM (308 w, 3 d)
Wed, May 29
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.
Tue, May 28
Mon, May 27
Sun, May 26
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.
Fri, May 24
hmmm I have one suggestion,
Tue, May 21
Sun, May 19
can you update status of this diff?
is it okay we go Part_XXX ?
May 12 2019
the idea looks good but the document need to be checked by @segfaultxavi..
and I think property_string_add/del is better to avoid some confusion of text_set/get
May 10 2019
May 9 2019
yeah as I told, this is just readability and preference problem so author think this is right, let's push it.
okay then, I think its ready to accept.
May 8 2019
I think code looks fine, but I found few preference coding styles,
I don't have strong opinion so if you thing current way is good then I'll be accept the patch.
May 2 2019
any opinion about Efl.Part? or naming?
code and idea looks good to me, but it is quite hugh code so it would be better to have some test or examples.
do have any plan for this?
Apr 26 2019
test passed with dependencies skipped patch.
okay let me try the build and other test. give me minutes.
opps sorry I didn't see that.
should we wait the opinion of @segfaultxavi ?
I like the idea of this patch,
but could be better to give simple explains about custom-mapping as comment for the test writers.
I got the point after reading the efl pack at document....
though it sound like....VERY WEIRD to me..
but it's @jpeg 's design.... and we should have to fallow the definition.
thanks for updating this feature.
code could be duplicated because they are almost same item-based widget, except the layouting... but I don't know what you mean second layout function.
our plan is support list and grid layout with pack-interface on simple case and MVVM interface on more complex or hugh data handling.
efl_ui_list was written before efl_ui_grid, and I planed to use efl.ui.box internally for simple implements, and it works as well for list layout, but
about grid requirement comes, I couldn't use box anymore so I have to make whole pack interface internally.
Apr 25 2019
stringshare_add also check hash and if it already hashed, not generated new stringshare.
this looks valid fix to me.
looks good to me.
Apr 24 2019
looks valid fix. though it may user fault, I agree we should give error message and exception handling.
if user input is wrong... I think we should fail the request not rollover the index...
looks valid fix. thanks.
Looks valid fix. thanks for fixing it.
Apr 23 2019
Apr 18 2019
looks good and clean to me.
I'm little bit worry about 32 bit system needs in the future on tizen side,
but currently it seems we all uisng 64 bit system and it won't be a problem.
I've recently faced some signed-unsigned default datatype issue on char,
so using strict datatype could be nicer to avoid such problem.
lets to discuss again on this matter after all infrastructure is ready :)
Apr 17 2019
code looks good, only few question about uint64 and exclusive term.
code looks fine but as I remembered there are some question about uint64... do we really need to use uint64 not general integer?
looks good to me,
@segfaultxavi do you have other opinion?
Apr 8 2019
so do you think we need to restrict factory input as Efl.Ui.Item_Factory only? or just change the property name as factory not item_factory?
I like the first idea, cause every code of list and grid will guess the object created from factory is Efl.Ui.Item not other class,
so if it comes something else, it is really hard to handle exceptions.
this patch is abandoned after create new patch D8582.
rerfactoring on item default and renaming empty item will be continously updated.
I was told about D8568
fix typo and examples
remove unnecessary po changes.
Apr 7 2019
sorry I made it and I have a plan to update this to using Efl.Ui.Item_Part_Icon and End not generating same part repeatly, but in here I was thinking that doc need to be updated,
can you update depended patch?
is this patch ready to go?
please comment more detail about this patch in commit-message,
and rebase on latest master.
Mar 25 2019
Mar 24 2019
sorry for late actions.
sorry for late review.
on the purpose of removing unnecessary order setup, this looks valid patch.
Mar 21 2019
@zmike, we have some testsuite for this elm_object_orientation_mode_disabled_set and it fails after your refactoring of this method.
the code looks never change once it disabled in non-layout case, I think it need to be fixed like this.
Mar 10 2019
this is not a final version, only buildable one. need to figure it out which one we need and not in both of grid view and list view
Feb 26 2019
Feb 25 2019
remove unwanted files
it looks zmike disagreed and I respect orignal authors opinion.
I really not sure but if we goes the event name as properties,changed, it sound more natural to change the other event name as properties,bound?
I mostly prefer the singular name on the APIs and Events, but unity is also very important thing in my thought.
is this property bound only come with single property not a list?
then it sound correct.
I'll change my review status after you pointing what is right.
Feb 13 2019
looks valid patch for me.
rebasing and update while to for statement.
this bug is detected by our coverity and I think this is right fix.
also there are some warns about memory leak of cbuf, but it looks reallocation of tbuf, so it looks safe on my view, but I hope you double check it.
Feb 12 2019
but as you see the code,
in realize case,
it get the return from elm_widget_item_tooltip_window_mode_set which redirect elm_object_tooltip_window_mode_set,
and in elm_tooltip_window_mode_set,
it returns input disable.