Could you check this task ? I also agree with JackDaniel.

Could you share the progress of this work ?

Do we have a way something like ...

I think customizing for Tizen could be discussed privately.
Except that, what are left for this task ?

@cedric welcome back :)
@Jaehyun_Cho

I also agree with @lauromoura that we don't need to wait for the works of @lauromoura.
Eo class inheritance refactoring should be done independently with his C# binding works.

I agree with the opinion of @bu5hm4n if the way that can make you happy can not be realized soon.
If you have some idea about how to fix (or improve) the bad construrctor system, could you share your idea here ?

Please check inline comment ~

Could you explain how to check the results for automated test cases In devs/felipealmeida/tct ?

@felipealmeida
We only need to include the methods which are "implemented" by the specific class.
That is, we don't need to include the method "not implemented".

@felipealmeida
Could you take care of the case of "efl.ui.Button should be changed to Efl.Ui.Button" together ?
Plus, will you update this to the master branch directly ?
Or, if you are managing another branch for this work, please share the branch name.

Please give a feedback whether to keep this patch or not.
I think we already have another way to communicate for this subject.

Could you give a feedback on this ?

This was a prototyping of new theme for efl_ui_xxx. And I can abandon this because it's already applied by @singh.amitesh.

Could you give a dicision whether to keep this patch or not ?

@eunue
Could you abandon this patch ?

I hope this patch would be updated together with new patch which introduces new MBE class.

@cedric
Oh. ok :) Then, everything is good.

This work includes simplify efl_ui_slider (it includes too much feature inside as a default slider class).
Could you explain why this thing should not be applied on master ?

I've added some inline comments.

I don't know whether B is doable.
To support with B concept, we need to give description what types(or classes) are available for transition_set(or indicator_set).

@cedric
Ok. I got it.

I'm also confused with the concept you talked.
If we want to make "value" as a property for efl_ui_mbe, it should have specific data type.

@cedric
Thank you for your feedback :)

@cedric
I think internal things could be arranged later.
After closing this task, @eagle001 needs to apply new efl_ui_scrollable to efl_ui_xxx classes.
(not for elm_xxx class which would be covered by elm_interface_scrollable. I don't think replacing elm_interface_scrollable to efl_ui_scrollable is urgent)

Ok. Let's try to merge [1] and [3]....

In T5358#112782, @cedric wrote:

I think you have summarized every option quite well. I do just have a question about [2] and why you think that this is impossible to decide what kind of item UI should be created when entry input happened. I would have expected that the UI item would be choosen depending on the input and some global state.

You mean that an application needs to choose specific item UI for each entry input. Am I right ?
I don't think application developers may want to do this by themselves.
This should be the one of major features of MBE.

Also I am thinking of another variant that I can see like :
MBE class + MBE item class (child of button class) instantiation on input parsed event.

The idea would be that when you press enter an event is fired with the inputed text as part of the event information. From there the user can decide to filter it out, or create any object that would be of MBE item class. The MBE would get back the text by doing text_get on the MBE item that get packed in. Allowing for changing the text easily if scenario require it.

With this idea, we can support the concept of "MBE class + MBE_ITEM(Item UI)".
But, as I talked before, I am sure no application may want to add an item everytime entry input is happened.
Plus, if this work would be done by application side, MBE is only a set of buttons. Nothing else.

@cedric
I think we need to think about the pros anc cons for each suggestion.

As @CHAN talked, we want to develope time and date widget classes for EFL and Application developers togehter.

@cedric
Ok. I will ask @bowonryu to modifiy his patch based on the idea of [2].

I think that efl_part(page, "indicator") is enough with text_set, icon_set, and content_set.
That is, we don't need to think about text2_set or icon2_set.

In T5317#112200, @bowonryu wrote:

Share the prototype.

https://phab.enlightenment.org/D5847

@Jaehyun_Cho
If each Navigation_Bar needs different Navigation_Frame, then I think #2 is better.
If every Navigation_Bar needs only one Navigation_Frame with title area, then #1 looks better.

@cedric
I think @eunue is handling this work in https://phab.enlightenment.org/D5832.
So we can abandon this contribution.

In T5358#111959, @cedric wrote:

I agree we should focus on making it a simple MBE (meaning not handling MVVM nor vast amount of content). Now, I have been wondering if we could not use the pack interface to add new item and have a specific expected item type that would be the only type accepted inside the MBE. This is kind of with item, except that the item will be real object and that they will be build outside of the MBE (This would give more freedom for customisation).

I need to be look at current MBE, but I think that MBE does create some object itself automatically, no ? If so, we have to either add an event that would expect a call to add an item to the MBE be done there or we register a factory type of object that would automatically do the conversion. I know that you guys are not at ease with factory design pattern, so if the event is good enough, we can start with that and add factory support later as they are orthogonal and won't impact the API.

Hmm. I want to get the spec of Efl.Ui.Tab.Indicator.
Based on your basic idea of this, does the class include UI or not ?
If it includes UI, then what is the difference between the new class and old elm_toolbar ?

@cedric
If my understanding is correct developers don't need to know about the existence of Efl.Ui.Tab.Indicator and Efl.Ui.Tab.Pager,
because developers will do (in C#) ....

In T5358#111930, @Jaehyun_Cho wrote:

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);

IMHO, efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change"); is better.
i.e. efl_ui_multibuttonetnry_item_text_set(obj, index, text) because the object index means like obj[i].text = "ABCD";
So I think keeping the order is better.

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

Dear. @cedric
I would give some information for better understanding.
Efl.Ui.Pager (@eunue is creating) supports Efl.Pack interface to insert contents in it.
So, the above Efl.Ui.Tab_Pager should support this interface together.

Could you update your Efl.Ui.TabPager Class definition here to get the review from @cedric and @eunue together :)

We will create new tab pager so, removing this commit looks ok for me.

I added some inline comments. Please check them.

@cedric
I need to handle this problem by myself because @eagleeye is in education for a month.
Could you decribe what are the error prone codes ?

@jpeg
We had not discussed about this, but I don't think it is needed now.
Then, could I close this task after @eagleeye finishes https://phab.enlightenment.org/T5319 ?

1. Stacker, Frame_Stacker or Frame_Stack ? If this will only allow to insert Frame object, then Frame_Stack looks good.
2. I also agree to promote it to the top.
3. What is "title_bar" ? Text area for title ? or ... background area of title text ?
4. I think many applications may want to pull their own Layout object. If we will only allow frame object, then , at least, we need to make a empty frame class for them.

Could we close this task ? Or, are there something remained to do ?

@smohanty
Would you share the plan for this task ?

@bu5hm4n
I want to get the idea about how to support legacy focus custom chain.
Do you have any plan for that ?

@Jaehyun_Cho
Would you share the class specification on this task ?

@jpeg
There is nothing left for this. Later, we need to do something more, then I'll create new task :)

Modify some wrong words in header file

@herdsman ping :) Could you update your idea on this task ?

@jpeg
"Today" cannot be changed. That is the role of god :P joke.

@jpeg Sure, you can see it elementary_test -> "Efl Ui Calendar".

bg_add is still ambiguous for me. Except that I don't have any objection about your codes :)

@cedric
I want to know the progress of this work - with simple factory thing together.

I made the first version of new calendar.
And I will do some more works to close this task.

• fix make file to include some headers

• add validating with mktime for each date setting
• fix some docs
• rebasing

fixed some docs

• change group_add/group_del to constructor/destructor
• add return value for date_min, date_max, and date
• fix wrong date setting when the value is less than min or greater than max

Modificaion on jpeg's comment.

Please check my inline comments :)

I think we need to think about the best way - how to keep the backward compatibility well.

Right !! I just found one problem not fixed for [Case 1].
Sorry for making you confused by re-openning this task.

For the [Case2], I also did some debugging, and want to share the result.

For the [Case 1], I did some debugging on this.
And, I could not understand well about "_border_flush" (which is in efl_ui_focus_manager_sub.c file).

Including this API, most of elm_object_focus_xxx APIs are woking not properly.
Do you have any plan to test all the elm_object_focus_xxx APIs to keep the backward compatibility ?