Rebase code based on the latest master branch and Free array in test_ui_spin_button.c

Please remove undefined properties and methods from Efl.Ui.Slider in test_ui_scroller.c (e.g. efl_ui_slider_part_indicator_visible_mode_set)

The interval changes will be considered in other patch.

In Efl.Ui.Slider_Interval, in herizontal mode, low value is moved by wheel and key but in vertical mode, high value is moved by wheel and key.
IMHO, the same values should be moved. (either low value or high value)

Fix to install elm_slider.eo.h correctly.
Otherwise, build error occurs on efl application.

As I tested elementary_test, the vertical slider with mouse wheel works the opposite direction I think.

This issue has been fixed. Thank you :)

Now this patch is rebased on the latest master.

Update code to rebase on latest master and to fix errors and warnings.

Update code to resolve conflict on master

test_efl_ui_tab_pager is changed to test_ui_tab_pager to synchronize with other cases.

The following diff is added to this patch to apply new theme naming rule.
Otherwise, page content set and transition do not work.

In D6008#102810, @zmike wrote:

In D6008#102809, @Jaehyun_Cho wrote:

In D6008#102804, @zmike wrote:

This patch should not have been accepted as it contains non-namespaced parts. T6911

@zmike

Sorry I checked your email from the mailing list after submitting this patch.

I've uploaded a patch to change the part names (b8de04d77f63f5f305b0ccd2670f1d908ba4bf7d)

Thanks!

Do you think it would be useful to have something which automatically checks the default theme for this during build to avoid future issues?

In D6008#102804, @zmike wrote:

This patch should not have been accepted as it contains non-namespaced parts. T6911

The following diffs are added to this patch to support unpack and to fix elementary_test errors (win ref error and unpack crash).

Please check the comments.

Please change to "Efl.Ui.Tags" for the test case name.

Please remove unused variables to remove warnings.

Please check the comment for rebase and removing warnings.

I think there is something to modify on this patch.
Please check the patch in devs/jaehyun/efl_part_legacy_remove_final branch.

There is a build error as follows.

efl_ui_datetime.c, efl_ui_datetime.eo, and efl_ui_datetime_private.h files are missing in this revision.

In D5969#102040, @cedric wrote:

In D5969#101962, @Jaehyun_Cho wrote:

In D5969#101789, @cedric wrote:

Just a question here, did you look at how it would look like with bindings ? I am thinking we might want an API that would be more a set/get with an array/hash of value+label. We could use either an Eina_Value, an Eina_Array or an Eina_Hash. The use could look like one of the following :

spin.special_values = { 1: "January",  2: "February", 3: "March", 4: "April", 5: "May", 6: "June", 7: "July", 8: "August", 9: "September", 10: "October", 11: "November", 12: "December"};
spin.special_values = { { value: 1, label: "January" },  { value: 2, label: "February" }, { value: 3, label: "March" }, { value: 4, label: "April" }, { value: 5, label: "May" }, { value: 6, label: "June" }, { value: 7, label: "July" }, { value: 8, label: "August" }, { value: 9, label: "September" }, { value: 10, label: "October" },  {value: 11, label: "November" }, { value: 12, label: "December"} };

I think that using Eina_List with Eina_Hash is good idea if special_values = { { 1: "January" } } is the only thing we need to write for C#.

However, I worry about the usage in C. Because the hash is consist of { double: string } and it is complicated to support double key for now. (eina_hash_new with key_length, key_compare, key_hash functions are required)

Hum, I missed that it was double. Indeed, not a great index for a hash. Not just in C, but everywhere.

BTW, I think that using Eina_List with Eina_Value is not a good idea because it requires many additional information to write (i.e. value, label).

Well, it is less to type than efl_ui_spin_special_value_add or special_value_add for namespaced language :-) In C, it should also become straight forward to go with an array inside an Eina_Value. You should be able to do something like :

// Provided by Efl_Ui.h somewhere
typedef struct _Efl_Ui_Spin_Special_Value {
  double value;
  const char *label;
} Efl_Ui_Spin_Special_Value;
EINA_VALUE_STRUCT_DESC_DEFINE(Efl_Ui_Spin_Special_Value_Desc, NULL, sizeof (Efl_Ui_Spin_Special_Value),
  EINA_VALUE_STRUCT_MEMBER(EINA_VALUE_TYPE_DOUBLE, Efl_Ui_Spin_Special_Value, value),
  EINA_VALUE_STRUCT_MEMBER(EINA_VALUE_TYPE_STRING, Efl_Ui_Spin_Special_Value, label));
 
Efl_Ui_Spin_Special_Value values[] = { { 1, "January" }, { 2, "February" } };

Eina_Value *v = eina_value_array_from(EINA_VALUE_TYPE_STRUCT, Efl_Ui_Spin_Special_Value_Desc, values);
 
efl_ui_spin_special_values_set(obj, v);

We are missing the eina_value_array_from() function, if I have time, I will write it tomorrow, but if you can cover it before me go ahead with that one.

@felipealmeida how would that look like in C# ?

raster, thank you for your feedback.

In D5969#101789, @cedric wrote:

Just a question here, did you look at how it would look like with bindings ? I am thinking we might want an API that would be more a set/get with an array/hash of value+label. We could use either an Eina_Value, an Eina_Array or an Eina_Hash. The use could look like one of the following :

spin.special_values = { 1: "January",  2: "February", 3: "March", 4: "April", 5: "May", 6: "June", 7: "July", 8: "August", 9: "September", 10: "October", 11: "November", 12: "December"};
spin.special_values = { { value: 1, label: "January" },  { value: 2, label: "February" }, { value: 3, label: "March" }, { value: 4, label: "April" }, { value: 5, label: "May" }, { value: 6, label: "June" }, { value: 7, label: "July" }, { value: 8, label: "August" }, { value: 9, label: "September" }, { value: 10, label: "October" },  {value: 11, label: "November" }, { value: 12, label: "December"} };

In short, we have 4 options as follows.

In D5934#101947, @cedric wrote:

In D5934#101826, @Jaehyun_Cho wrote:

<Solution only for Efl Ui Interface Theme>

1. In efl ui interface EDC, I want to send signals with part name itself as follows. Both "elm.swallow.content" and "content" parts exist, then "state,efl.content,set" "efl" and "state,content,set" "efl" are emitted.
2. Keep "efl" only for source. So "state,efl.content,set" "efl" is emitted instead of "efl,state,efl.content,set" "efl".
   
   What do you think about the above?

What about "state,content,set" "efl" ?

Please check the comments

@raster
I apologize it's my fault.
I will check carefully.

Thank you for answering the questions. The answers for my 1st and 2nd questions are clear.

Please check the comments

I have questions about your comments as follows.

I think another name is better than special_value_add().

@cedric
I understand your point. But we think more about C# part interface here.
For the "background" part interface, background.color_set() would be used.
In this case, if the edc part name is "efl.background", then it would be confusing to application developer who customizes their own edc file.

Now in efl_ui_widget, if there is a sub widget in a widget, then the sub widget's theme should be written in widget's theme.
e.g. efl_ui_popup_alert creates buttons and the button theme is written in popup.edc.
The button group name is "efl/popup_alert/button"). And elm_widget_element_update() is called to load the group.

Please check the comments

I am thinking of providing the following events in Efl.Ui.Frame_Stack.

The Efl.Ui.Navigation_Bar eo is as follows to support back_button as its part object.

The Efl.Ui.Navigation_Frame eo is as follows to support title_bar as a property.

Please change the name to "Efl.Ui.Text_Alert_Popup".

Please change the test case window name to "Efl.Ui.Scroll_Alert_Popup".

@bu5hm4n
After applying the patch "efl_ui_focus_manager: move cleanup into one place" (ca2461c28027ae1a64ec89893e459cf76bdc1269), infinite loop case happens.

OK, I will make "bar" as a property of frame for better customization :)

In T5351#111617, @Jaehyun_Cho wrote:

@cedric @woohyun

For the title area of navigation frame, I have not decided how to design or implement it.
However, for now I have an idea as follows.

1. Introduce Efl.Ui.Navigation_Bar class.
2. navigation bar instance is automatically created inside navigation frame instance.
   
   Here, there are many things to think about.
3. is bar a property of navigation frame? or an efl_part of navigation frame? 2-1. if bar is a property, then is it ok to provide get/set to modify bar by application developer? 2-2. if bar is an efl_part, then how to modify bar's propery? and how to replace bar with other kind of bar? (e.g. replace Efl.Ui.Navigation_Bar class instance with Efl.Ui.Search_Bar or Efl.Ui.Tab_Bar class instance)
   
   @cedric @woohyun Please give me any feedback about this.

Efl.Ui.Popup.Anchor.List class probably requires its own item class or interface.
Since this class instance can be created by adding Efl.Ui.Popup.Anchor with list, the priority of this class is not that high.
I think it would be better that this class implementation is finished after other item based class implementation is finished.

In T5358#111963, @woohyun wrote:

@Jaehyun_Cho
I've refered the definition of pack_at in Efl.Ui.Pack interface.
(i.e. pack_at(obj, sobj, index)

If MBE case should be cared differently, you could be right - but, I do think keeping consistency would be better.
How do you think about this ?

In T5358#111926, @woohyun wrote:

@CHAN
I think below are correct. Please check whether I'm wrong.

efl_ui_multibuttonentry_item_append(mbe, 1, "test"); -> efl_ui_multibuttonentry_item_append(obj, text);
efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change"); -> efl_ui_multibuttonetnry_item_text_set(obj, text, index);

For the title area of navigation frame, I have not decided how to design or implement it.
However, for now I have an idea as follows.

This is the on-going classes for navigation.
Basically application developer creates Efl.Ui.Navigation_Frame class instance and push it into Efl.Ui.Frame_Stack class instance.

@CHAN
I am not sure if we need to handle field limit for DAY and AMPM.
What do you think?