- User Since
- Feb 15 2013, 4:22 AM (304 w, 1 d)
Fri, Dec 7
Could you check this task ? I also agree with JackDaniel.
Thu, Dec 6
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 ?
Thu, Nov 22
Fri, Nov 16
Oct 28 2018
Oct 19 2018
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 ?
Oct 16 2018
Oct 11 2018
Oct 5 2018
Please check inline comment ~
Oct 4 2018
Oct 2 2018
Could you explain how to check the results for automated test cases In devs/felipealmeida/tct ?
Sep 18 2018
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".
Sep 10 2018
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.
May 8 2018
May 2 2018
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 ?
Could you abandon this patch ?
Apr 23 2018
Apr 12 2018
I hope this patch would be updated together with new patch which introduces new MBE class.
Apr 11 2018
Oh. ok :) Then, everything is good.
Apr 10 2018
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.
Apr 8 2018
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).
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.
Thank you for your feedback :)
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)
Mar 29 2018
Ok. Let's try to merge  and ....
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.
I think we need to think about the pros anc cons for each suggestion.
Mar 28 2018
As @CHAN talked, we want to develope time and date widget classes for EFL and Application developers togehter.
Mar 27 2018
Mar 26 2018
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.
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.
Mar 13 2018
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 ?
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#) ....
I think below are correct. Please check whether I'm wrong.
Mar 12 2018
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.
Mar 8 2018
We will create new tab pager so, removing this commit looks ok for me.
Mar 6 2018
I added some inline comments. Please check them.
Feb 20 2018
Feb 13 2018
Feb 12 2018
Jan 18 2018
Jan 16 2018
- Stacker, Frame_Stacker or Frame_Stack ? If this will only allow to insert Frame object, then Frame_Stack looks good.
- I also agree to promote it to the top.
- What is "title_bar" ? Text area for title ? or ... background area of title text ?
- 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.
Jan 15 2018
Could we close this task ? Or, are there something remained to do ?
Jan 14 2018
Would you share the plan for this task ?
I want to get the idea about how to support legacy focus custom chain.
Do you have any plan for that ?
Would you share the class specification on this task ?
Dec 11 2017
There is nothing left for this. Later, we need to do something more, then I'll create new task :)
Dec 4 2017
Nov 30 2017
Nov 26 2017
Modify some wrong words in header file
Nov 20 2017
@herdsman ping :) Could you update your idea on this task ?
Nov 13 2017
"Today" cannot be changed. That is the role of god :P joke.
@jpeg Sure, you can see it elementary_test -> "Efl Ui Calendar".
Nov 5 2017
bg_add is still ambiguous for me. Except that I don't have any objection about your codes :)
Oct 26 2017
I want to know the progress of this work - with simple factory thing together.
Oct 25 2017
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
Oct 24 2017
- add validating with mktime for each date setting
- fix some docs
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
Oct 23 2017
Modificaion on jpeg's comment.
Oct 22 2017
Oct 13 2017
Please check my inline comments :)
Sep 19 2017
I think we need to think about the best way - how to keep the backward compatibility well.
Aug 31 2017
Right !! I just found one problem not fixed for [Case 1].
Sorry for making you confused by re-openning this task.
Aug 30 2017
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 ?