class Efl.Ui.Spin @beta ├ (E) changed ├ (E) min,reached ├ (E) max,reached
Action items:
- Move the 3 events to efl.ui.range_display Adapt the spec test suites accordingly
- Move wheel implementation to efl.ui.spin_button.
class Efl.Ui.Spin @beta ├ (E) changed ├ (E) min,reached ├ (E) max,reached
Action items:
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | None | T8097 efl_ui_spin_button | ||
Resolved | None | T7897 efl.ui.spin | ||
Resolved | None | T7894 efl.ui.range_interactive | ||
Resolved | None | T7895 efl.ui.range_display | ||
Open | None | T7896 efl.access.value | ||
Open | None | T7586 efl.access.widget.action | ||
Resolved | CHAN | T7898 efl.ui.format | ||
Open | None | T7912 enum Efl.Input.Object_Pointer_Mode | ||
Open | None | T7573 efl.ui.l10n | ||
Open | None | T7566 efl.ui.i18n | ||
Open | None | T7574 efl.ui.selection | ||
Open | None | T7913 function Efl.Ui.Selection_Data_Ready | ||
Open | None | T7914 struct Efl.Ui.Selection_Changed | ||
Open | None | T7915 enum Efl.Ui.Selection_Type | ||
Open | None | T7916 enum Efl.Ui.Selection_Format | ||
Resolved | None | T7578 efl.ui.view | ||
Open | None | T7917 enum Efl.Ui.Activate | ||
Resolved | None | T7919 enum Efl.Orient |
struct @beta Efl.Ui.Spin_Special_Value { [[Special value]] value: double; [[Target value]] label: string; [[String to replace]] }
Totally agreed. I think we should have simply implemented the format mixin on this here...
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 ?
And I still don't know how would you implement the special values with a format string.
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.
I think it does make sense to move the 3 events to the range_value_display interface ?
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? :)
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.
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 :)
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 ?