hmmm I have one suggestion,
Tue, May 21
The C# bindings now automatically add the Part suffix, so we do not need to use any prefix or suffix. label, icon and extra should be good enough names for parts now.
The problem is that Eolian is still enforcing that part names do not clash with property names. Can this restriction be removed, @q66?
Also, be careful, there's still commented-out code in efl_ui_grid_default_item.c
Sun, May 19
can you update status of this diff?
is it okay we go Part_XXX ?
Sun, May 12
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
Fri, May 10
Thu, May 9
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.
Wed, May 8
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.
Thu, May 2
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?
Fri, Apr 26
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.
Thu, Apr 25
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?
I agree with the intention of this commit, which is putting together in the same class repeated parts from different classes.
However, I think we can go even further. Looking at the patch, it looks like the parts for Efl.Ui.List_Default_Item and Efl.Ui.Grid_Default_Item are identical. Could these parts be moved to Efl.Ui.Item, for example?
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.
Feb 11 2019
Feb 1 2019
It works very well. thank you so much :)
oh its wrong patch.
I tested and it fix the problem well :) thank you.
fix the dependency file including bugs
It appears that we are recursivly skipping interfaces, but not on the direct implementer. I will look later next week into it.
remove wrong file includes
- eo: Fix efl_isa for class checking of recursively inherited types
Do you have a old efl_ui_layout.eo.c arround somewhere in your tree ?
I think I resolve the problem by recursive calls of efl_isa for mro
The issue case is easily found in example of efl_ui_list_view_example_1.c
looks something wrong in the patch.