Page MenuHomePhabricator

efl.ui.spin
Closed, ResolvedPublic

Description

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.

Related Objects

StatusAssignedTask
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
OpenNone
OpenNone
ResolvedCHAN
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedNone
OpenNone
ResolvedNone
bu5hm4n created this task.May 3 2019, 11:58 AM
bu5hm4n triaged this task as TODO priority.
zmike added a comment.Jun 12 2019, 9:49 AM
struct @beta Efl.Ui.Spin_Special_Value
{
   [[Special value]]
   value: double; [[Target value]]
   label: string; [[String to replace]]
}
zmike added a comment.Jun 12 2019, 9:50 AM

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

zmike moved this task from Backlog to Evaluating on the efl: api board.Jun 12 2019, 9:51 AM

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 ?

zmike added a comment.Jun 13 2019, 6:11 AM

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 ?

zmike added a comment.Jun 14 2019, 7:15 AM

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.

zmike added a comment.Jun 14 2019, 9:07 AM

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?

zmike added a comment.Jun 18 2019, 9:00 AM

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.

zmike added a comment.Jun 18 2019, 9:24 AM

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

CHAN claimed this task.Jul 7 2019, 10:05 PM
bu5hm4n claimed this task.Jul 7 2019, 10:31 PM
bu5hm4n added a subscriber: CHAN.

Stooop i have bending work here

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 ?

segfaultxavi updated the task description. (Show Details)Jul 8 2019, 9:21 AM

Yeah, they belong there.

bu5hm4n updated the task description. (Show Details)Jul 8 2019, 9:24 AM
Diffusion closed subtask T7562: efl.input.interface as Resolved.
bu5hm4n removed bu5hm4n as the assignee of this task.Jul 12 2019, 6:21 AM

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

CHAN added a comment.Jul 15 2019, 10:15 PM

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

CHAN added a comment.Jul 15 2019, 10:27 PM

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

CHAN added a comment.Jul 17 2019, 6:42 PM

@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 ?

bu5hm4n updated the task description. (Show Details)Jul 31 2019, 2:48 AM
segfaultxavi updated the task description. (Show Details)Jul 31 2019, 4:00 AM
bu5hm4n updated the task description. (Show Details)Jul 31 2019, 5:10 AM
bu5hm4n updated the task description. (Show Details)

This looks good now ?

bu5hm4n moved this task from Evaluating to Stabilized on the efl: api board.Jul 31 2019, 6:15 AM
zmike closed subtask T7578: efl.ui.view as Resolved.Sep 26 2019, 8:12 AM