This special_value is pretty weird. It feels like it should be a format thing?

Totally agreed. I think we should have simply implemented the format mixin on this here...

The min max events, should they be on the range interactive interface ?

I agree with both of the above ideas.

How would you implement the special values with a format string? The Efl.Ui.Format mixin is still beta and I do not understand how format_string and format_cb interact.

Also, the min,max events belong to the Efl.Ui.Range_Display interface, since it's the one actually defining the min and max values, and the range value. The docs for Range_Display are all wrong, btw ?

I agree with both of the above ideas.

And I still don't know how would you implement the special values with a format string.

I think you would use the callback?

I've written my concerns in T7898.

OK, I think the special_value property is redundant if we use the Efl.Ui.Format mixin. Probably a leftover from older times.

How about we remove special_value from here and we study if it is worth adding it to Efl.Ui.Format?

I think it's a corner case. This should be handled through the callback I think, if I'm remembering correctly how that works.

The callback can handle every case. format_string is useful for printf-like strings, and I think special_value could be beneficial too.
I would not consider it a corner case, since that is how spinners with weekday names, or month names are implemented.

Yea I read this before I saw the format ticket comments.

Please see the revisions stack ending at D9232

I think it does make sense to move the 3 events to the range_value_display interface ?

Yeah, they belong there.

We maybe want to clarify if we want to have the mouse-wheel interaction here or on the spin button. I can think of other usecases for this widget here, where we can simply inherit from it, apply a UI to it that calls value_set and everything is good. But in that case the mouse-wheel interaction would be a little bit ... misleading?

I am still not clear on what is the difference between Spin and Spin_Button., and what interaction does each one support. Can you help me? :)

@segfaultxavi

First Design Concept.

spin can set a value and change the value using key event (when gets focus).

spin button inherits spin and it has two buttons so user can change the value using that button.

spin scroller inherits spin and its scrollable.

spin scroller is not implemented yet. :)

@bu5hm4n Could you please tell me more detail about above comment? mouse-wheel thing i mean.

@CHAN In my theory, i am thinking about if spin could be just a plain read only widget. The UX (the interaction with the mousewheel event) is then a bit wrong in efl_ui_spin.c and maybe should be moved to efl_ui_spin_button.c.

Following this, we would have a clear separation between the implementation of the range API, and the UX defined by the inheritoor of Efl.Ui.Spin.

@bu5hm4n Thank you for the detail.

Do you mean that the Efl.Ui.Spin doesn't take to receive events and handle it? or only mouse-wheel event is not for Efl.Ui.Spin?

If your opinion is the former one.

We need to support below UX in various case.
When the Efl.Ui.Spin gets focus and user press Up and Down button to change the value.

I think there should be minimal functionality for range handles.

If your opinion is the latter. i agree with that.

thanks.

I am talking about mouse-wheel event :)

@bu5hm4n @CHAN @segfaultxavi

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)

That's because it's not an interactive widget anymore :)

How do you think about this ?

@bu5hm4n said that Efl.Ui.Spin could be a read-only widget, so maybe it's OK to keep it as an instantiable widget.

I see no benefit in making it abstract if the widget is actually instantiable. It looks like an artificial restriction. We'll document that this is meant as a base class and that it is not very useful on its own :)

@segfaultxavi

If there can be a usage with this, then, I have no objection.
Is there anything left to be discussed for this class ?

@CHAN Could you check one more time ?

This looks good now ?

+1

+1 :)

Good