- User Since
- Feb 15 2013, 4:22 AM (339 w, 5 d)
As @bu5hm4n talked before - there are lots of bad things in both efl_ui_slider and efl_ui_slider_interval.
fix build warnings
I also like the idea of @cedric to keep all the discussions here.
But, because we only have limited time for this work, I think it can be good to talk in chat for long discussion.
(And then, let's share the result here)
Ok. I'm moving to Action Item #3.
If anyone has another idea on the slider class (and it needs big change), please let me know asap :)
Some questions while checking the description of this task.
You are so fast ! You added reply just after I deleted my comment !! HAHA. (I needed more time to arrange my idea)
Anyway thanks for the reply.
Mon, Aug 19
Thank very much. I did update the codes to fix the things you indicated.
Let me know if there is anything wrong.
update test suite for more events
update codes to solve the failures in test suite
fix wrong indentation
Fri, Aug 16
I will try the work item #2, and try to estimate the things you are worrying about.
Thu, Aug 15
Thanks for sharing the current status :)
You are not such a horrible person :)
Wed, Aug 14
Is this ok for following dependencies - or Do we need to remove this interface perfectly ?
Please look into this task with T7383.
I cannot trace the discussion results so far.
Could you do the action item on the description ?
Plus, if you are thinking of another action item - please share it here.
I think this looks ok - because legacy scroller has proved that this enum is needed with this definition.
Let's make a list of work items here (and add them in the description comment)
I think below things need to be considered together as work items.
Do you have other candidate names for Text classes ?
I also like the idea of WPF, but I hope to hear your ideas.
Hmm. I am still confused which one is better.
And, I could not find similar names in other platforms, so it is much difficult problem for me.
(Plus, I'm not that good person for naming !!)
Tue, Aug 13
Are you ok with "wraparound" and "text_editable" ?
Then, I'll add action items, and will do by my own soon.
If my memory is correct -
when we began these interface works, upstream developers discussed together about STYLE.
Could we move this task to "Stabilized" ?
So, could I add below two work items ?
I hope so :) no more feedback ?
Wed, Aug 7
Mon, Aug 5
Sat, Aug 3
I also like wraparound.
Fri, Aug 2
How about discussing "user,changed' later after the next release ?
When I asked about this, I just thought that it was a simple thing by adding it to efl_ui_slider only.
But, while discussion, I have felt like this one needed to be handled with more general consideration for whole widgets.
So, I think it would be better to discuss this after doing the basic interface works.
Thu, Aug 1
I checked the first commit of this widget class.
I updated a test suite. Let me know if the test case has something wrong.
update test suite
Wed, Jul 31
This commit depends on D9454.
revert back wrong modification
Mon, Jul 29
If there can be a usage with this, then, I have no objection.
Is there anything left to be discussed for this class ?
After removing event implementation (for mouse-wheel event),
it would be better to keep this class as abstract one.
(It just implements some interfaces relating range things)
Sun, Jul 28
I think your research of other platforms could be very useful for this discussion :)
Can you share the results of research ?
I made a patch for work item #1. (D9427)
After this patch, I'll make two patches additionally for #2 and #3 at the same time.
Fri, Jul 26
So, my question was that it could be confused to the developers who are familiar with "clicked" (used as clicked,primary in the other platforms) .
Because they will use "Clicked" event without any doubt.
Oh, I was confused a bit.
While doing the work items, I have two questions.
Thu, Jul 25
I hope this work can be done till the end of July.
Wed, Jul 24
I have been talking about STATIC class with @felipealmeida, and will create another task to talk about this deeply.
Jul 19 2019
Thanks for your explanation.
So, can we summarize the work items like -
Jul 18 2019
Let's check this together ~
@eagleeye and I also want to check the things together ~ :)
Jul 17 2019
I agree with that idea - and I hope it could be generated as STATIC class in other bindings (such as C#).
Jul 16 2019
For #2, we can choose one of below candidates.
Jul 15 2019
Before beginning to modify codes, I have some questions.
Jul 14 2019
Jul 13 2019
I also agree that "selected" is weird, but I'm sorry to not give good new name.
I will talk with @Jaehyun_Cho and try to verify whether "entry's longpress logic" can be applied to other widgets together.
- The other case is in case that there is a selection in progress the longpress timer is stopped, which is IMO a perfect case of where this does make sense. So i would totally agree on adding such a API to the mixin.
I focused on the "definition of Efl.Ui.Clickable class", and felt little bit ambiguous that there would be a method for "longpress" for clickable feature.
Just my opinion :)
Jul 11 2019
I think that tags (=formats) which can be used with EFL markup text are listed up in evas_textblock_legacy.h.
(I'm not sure whether this is something you want to know)
Maybe we can add a markup_type property which is an enum to support multiple types?
Although that means we need to keep the original markup around in case the property is changed later and we need to re-interpret the markup string.
Probably a better approach is a set_markup method with a type parameter besides the actual markup text, instead of a plain markup property.
If the type parameter has a default value then we do not add any complexity for the user (for languages supporting default parameters).
I'm wonderting what you mean with "markup_type". I don't know whether there can be multiple types for this feature.
What I only know is that there are only utf8 and markup which need to be covered by efl.canvas.text.
(Please let me know if I'm wrong)
no objection :)
All look reasonable for me, too.