[Feature Request] Mouse input device support

[XuNeo]

Introduce the problem

Currently we have pointer and encoder type of input device. But for platform that uses mouse directly like in simulator, the scroll wheel should not be treated as simple encoder.
Ideally the wheel could also scroll the page or change slider value or send event to whatever widget currently focused.

Add a unified solution for mouse use case could benefit lot of user cases.

Examples and cases

Suggested solution

[kisvegabor]

We can add an lv_point_t scroll field to lv_indev_data_t. If it's set, a widget will be scrolled accordingly. However, I'm not sure which widget should be scrolled?

1. The widget under the current pointer position?
2. The last activated widget?

(They can be different if the cursor was moved without clicking.)

I vote for 1) because PCs work like this as well. (At least my Linux Mint)

[XuNeo]

For touch screen with crown, the focused widget could be used for sending event to.

[kisvegabor]

With crown, can you position the "cursor" above the focused widget so that we can use option 1) ?

[XuNeo]

With crown, can you position the "cursor" above the focused widget so that we can use option 1) ?

That sounds a bit of hacky.
The focused state could be better to decide which obj to scroll right?
LV_OBJ_FLAG_CLICK_FOCUSABLE can be used by app to auto-focus widget by touch.
Indev will send scroll event if the focused obj is scrollable and send encoder value instead if non-scrollable?

I haven't investigate much on this, please do check if any other options available.

[kisvegabor]

I prefer scrolling based the object under the cursor to mimic PC behavior. I haven't clicked just scrolled:

At worst case we can make it a config option, but it would be better have a single solution which works in general.

What if we really create a function for that. Probably it would be the most flexible solution. I mean something like this in the indev read_cb:

if(scroll_up) {
  lv_indev_scroll_throw_manual(indev, lv_indev_get_last_clicked(), scroll_size, LV_DIR_TOP);
  
  //OR
  lv_obj_t * obj = lv_indev_search_scrollable_obj(&point, scroll_size, LV_DIR_TOP);
  lv_indev_scroll_throw_manual(indev, obj, scroll_size, LV_DIR_TOP);
}

[XuNeo]

cc @W-Mai

[W-Mai]

Maybe we can add a new hover state when pointer is enabled.

Auto scrolling occurs when the pointer is hovering an object.

[kisvegabor]

Auto scrolling occurs when the pointer is hovering an object.

That's my idea too. LV_STATE_HOVER is already added to LVGL but it's not used yet. I think we shouldn't add full HOVER support now, just find the object on and x,y coordinate which can be scrolled in the given direction.

[xaowang96]

With crown, can you position the "cursor" above the focused widget so that we can use option 1) ?

That sounds a bit of hacky. The focused state could be better to decide which obj to scroll right? LV_OBJ_FLAG_CLICK_FOCUSABLE can be used by app to auto-focus widget by touch. Indev will send scroll event if the focused obj is scrollable and send encoder value instead if non-scrollable?

I haven't investigate much on this, please do check if any other options available.

@XuNeo There may be a contradiction here. The crown should also support scrolling propagation, but it cannot be propagated after specifying focused obj.

[kisvegabor]

What do you mean by "rectifying"?

[xaowang96]

What do you mean by "rectifying"?

@kisvegabor It is a typo, it should be "specifying".

[kisvegabor]

There may be a contradiction here. The crown should also support scrolling propagation, but it cannot be propagated after specifying focused obj.

We could still say to try scrolling the focused object, but propagate the scroll if needed.

[kdschlosser]

what gets scrolled is whatever the mouse is hovering over. If that item is not able to be scrolled then it's parent is what gets scrolled. and if the parent is not able to be scrolled... etc etc all the way down to the screen level.

To further assist something like that you would need to add 2 events, one would be mouse_enter and the other is mouse_leave. when the mouse moves hot tests would need to be done to locate the object it is hovering over. if the mouse was not over the
object the last time but it is now then an event should be triggered that the mouse has entered a new widget but only after an event is triggered that it left a widget if it did leave a widget.

[XuNeo]

We could still say to try scrolling the focused object, but propagate the scroll if needed.

There's a corner case that a slider is focused and is not scrollable. But the parent of slider is scrollable.
The expected behavior should send event to focused slider.

Hovering on the slider should simply scroll the parent though.

So the logic for low level indev becomes that firstly check if there's focused obj, if so, send the event anyway.
Otherwise, send scroll event and propagate it to obj hovered.

[kisvegabor]

On our meeting we have concluded to create a new input device for it.

Is it required to add to v9.0, or adding it by the end of January is still ok?

[lvgl-bot]

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

[kisvegabor]

Not stale

[kisvegabor]

Continued in #5057