| |interface Efl.Ui.Range_Display @beta | |โ (P) range_value | |โ (P) range_limits
- Move changed min,reached max,reached here, add spec test suite for it.
| |interface Efl.Ui.Range_Display @beta | |โ (P) range_value | |โ (P) range_limits
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | None | T8097 efl_ui_spin_button | ||
Resolved | None | T7897 efl.ui.spin | ||
Resolved | None | T7893 efl.ui.slider | ||
Resolved | None | T7894 efl.ui.range_interactive | ||
Resolved | None | T7895 efl.ui.range_display |
Except the wondering why this interface needs to be separated with efl.ui.range_interactive (T7894),
this looks ok for me.
A few interfaces are only implementing efl.ui.range_display, others are implementing efl.ui.range_interactive. If we would not have this split, we would have a lot of unimplemented API.
Woops. I missed the extension relation between two interfaces.
That is, "Efl.Ui.Range_Interactive extends Efl.Ui.Range_Display"
Then, I am ok with current status.
We seem to have far more properties in our API with limit than with min_max, so OK, I buy that.
We might want to check, if setting limits to the same value (min=max) results in the implementor beeing disabled?
If you are meaning that "setting min = max" will call efl_ui_widget_disabled_set(obj, EINA_TRUE),
I don't like the way because I cannot imagine what would be happened when efl_ui_widget_enabled_set would be called on that.
I think just making the button (on the efl_ui_slider) not be movable on the slider looks enough.