As @bu5hm4n talked before - there are lots of bad things in both efl_ui_slider and efl_ui_slider_interval.

fix build warnings

In D9628#178653, @tasn wrote:

I haven't looked at the actual code, but I do plan on making textblock2 work on grapheme clusters too, so this is inline with that change.
Though maybe I'd wait with this until TB2 is in, hopefully in a few weeks?

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.

@tasn
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.

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

I will try the work item #2, and try to estimate the things you are worrying about.

@bu5hm4n
Thanks for sharing the current status :)

You are not such a horrible person :)

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.

@eagleeye
Do you think there can be any reason why this cannot be merged with T7924 ?
We may need to think about the future extension of each enum.

@SanghyeonLee
Could you give a reply on question of @bu5hm4n ?

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

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 ?

I also like wraparound.

In T7893#139361, @segfaultxavi wrote:

How would we do that? We make this release without user,changed events and add them afterwards? I'm OK with this but are these events required by any app right now?

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.

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

In D9455#175455, @bu5hm4n wrote:

Looks good, thank you :)
But can you add a event to efl_test_clickable.c in the spec test suite ? :)

+1 :)

This commit depends on D9454.

revert back wrong modification

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)

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.

Right.
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.

I hope this work can be done till the end of July.

I have been talking about STATIC class with @felipealmeida, and will create another task to talk about this deeply.

In T7893#138541, @segfaultxavi wrote:

I'm curious, why do you want to distinguish between changed and user_changed? What is the use case?

Thanks for your explanation.
So, can we summarize the work items like -

Let's check this together ~

In T7893#138409, @bu5hm4n wrote:

Just as a quick heads up of that widget:

@eagleeye and I also want to check the things together ~ :)

I agree with that idea - and I hope it could be generated as STATIC class in other bindings (such as C#).

For #2, we can choose one of below candidates.

Before beginning to modify codes, I have some questions.

In T8045#138313, @ali.alzyod wrote:

In T8045#138306, @woohyun wrote:

In T8045#138304, @ali.alzyod wrote:

Please check
https://phab.enlightenment.org/D9310

I don't like this way in the aspect of maintenance. (Plus, I'm not sure this works for all cases with user test cases)
This is because efl_ui_text never know when the longpress callback is called and aborted.
If there would be a change on "when the longpress callback is called", your logic needs to be modified.
That is, "sd->long_pressed" can be set to EINA_TRUE almost randomly in efl_ui_text.

So, I think that "supporting a way to abort longpress timer" would be better if we will decide to use efl.ui.clickable in efl.ui.text.

How do you think about this ?

Names are confusing.

Do you mean cancel Long-Press Event or Timer created inside efl_text_ui?
because created timer (old timer) never initialized so removing it make sense.

This is because efl_ui_text never know when the longpress callback is called and aborted.
inside the constructor efl_event_callback_add(obj, EFL_UI_EVENT_LONGPRESSED, _long_press_cb, obj); so it know when callback is called.

If there would be a change on "when the longpress callback is called", your logic needs to be modified.
That is, "sd->long_pressed" can be set to EINA_TRUE almost randomly in efl_ui_text.

The Issue here that for desktop environment, even if long press is called, it will wait until mouse-up happened after long press.
If this behavior is changed it will be very simple to fix.

So, I think that "supporting a way to abort longpress timer" would be better if we will decide to use efl.ui.clickable in efl.ui.text.
I think right now we can cancel the event, or at least unregister/register longpress event.

**How do you think about this ?**

Maybe I do not understand exactly what is main problem, but if you mean ability to cancel event. I think it is good feature.

In T8045#138307, @bu5hm4n wrote:

@woohyun After sleeping one night over it, I think we should add something like "abort_longpress()" to "Efl.Ui.Clickable". Other usecases:

• Rect selection in something like item_container. When the rect selection starts, longpress should be aborted.
• Drag and Drop: when a drag starts, we should abort the longpress. [...]
  
  So i like the idea of "abort_longpress" :)

I also agree that "selected" is weird, but I'm sorry to not give good new name.

In T7895#138264, @bu5hm4n wrote:

We might want to check, if setting limits to the same value (min=max) results in the implementor beeing disabled?

@bu5hm4n

In T8045#138304, @ali.alzyod wrote:

Please check
https://phab.enlightenment.org/D9310

In T8045#138252, @bu5hm4n wrote:

After reading the code of efl_ui_text:

• One case cancels the longpress in case that a mouse move to some other element happend, i think that is equal to what @Jaehyun_Cho implemented recently. Entry how ever does that a little more "high quality" and check for the finger size of elm, we can also implement that if this is generally needed

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

In T7858#137438, @segfaultxavi wrote:

What kind of markup do we actually use? Is this documented anywhere?

@segfaultxavi
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)

In D9274#171119, @bu5hm4n wrote:

@woohyun Can you create a task so we can discuss that further ?

no objection :)

All look reasonable for me, too.

In D9274#171085, @ali.alzyod wrote:

@woohyun

The Issue I am taling about is after applying the patch. (So are there more things to do to clear the times ?)

This will be changed when "efl.ui.clickable(T7847)" will have different name. Am I right?
If so, we may need to postpone removing @beta from this structure.