Skip to content

menu: the mouse wheel moves the list, not the selection - #19494

Open
KrisEnigma wants to merge 1 commit into
libretro:masterfrom
KrisEnigma:fix/menu-wheel-scroll
Open

menu: the mouse wheel moves the list, not the selection#19494
KrisEnigma wants to merge 1 commit into
libretro:masterfrom
KrisEnigma:fix/menu-wheel-scroll

Conversation

@KrisEnigma

@KrisEnigmaKrisEnigma commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

menu: the mouse wheel moves the list, not the selection

Closes#9633.

The wheel has always been MENU_ACTION_UP/DOWN in menu_driver.c. Every driver stepped the selection, one entry per notch. That is what a d-pad does. It is a poor match for a wheel, and it is why Ozone and GLUI feel broken next to their own click-and-drag, which already moves the list.

A wheel_scroll hook on menu_ctx_driver_t lets a driver take the notch as list movement. Ozone and GLUI implement it. XMB and RGUI leave it NULL, so they keep the old step: their list position is the selection.

Ozone queues notches and spends them where drag scrolling already clamps, so the wheel obeys the same top and bottom. Three rows a notch. Pointer over the sidebar scrolls the sidebar. Cursor mode is turned on because a wheel moves no pointer, and without that the hover code never runs, so the entry under the pointer is selected once the list settles.

GLUI reuses the animated scroll it already had for swipes. It declines while fullscreen thumbnails or a scrollbar drag are active.

The last piece is Ozone going back to the sidebar. That hides the thumbnail bar, which rewraps every entry and used to re-center on the selection. A pointer leaves the selection wherever it was resting, so the list jumped. preserve_scroll_on_compute keeps the same top entry in view. Material UI already does this when geometry changes without the list changing.

Independent of #19493, which reworks the Ozone pointer highlight. Either can go in first. Together they read better, since that one stops a highlight showing while the pointer rests between rows.

How to verify

Ozone (and GLUI, if you have a mouse):

  • Wheel a long playlist. The list moves. Selection follows the pointer, not the wheel.
  • Wheel with the pointer over the sidebar. The sidebar moves.
  • Hover a game at the top or bottom of the view, move left. The list stays put.
  • Open a playlist tab with the keyboard. It still scrolls to the remembered entry.
  • D-pad still steps one entry.

Tested on an LG OLED65G5 (webOS 10.3.1) with the Magic Remote pointer and wheel, Ozone with thumbnails on.

Ozone and GLUI already scroll from pointer.y_accel when you drag. The
wheel was MENU_ACTION_UP/DOWN in menu_driver.c for every driver, so a
notch stepped the highlight the way a d-pad does. A wheel_scroll hook
lets a driver take the notch as list movement; XMB and RGUI leave it
NULL and keep the old step.
Ozone queues notches and spends them in the same clamp as drag. Three
rows per notch. It also turns cursor mode on, because a wheel moves no
pointer, and without that the hover code never runs. GLUI uses the
animated scroll it already had for swipes.
Going back to the Ozone sidebar hides the thumbnail bar. That rewraps
every entry and used to re-center on the selection, which a pointer
leaves wherever it was resting. preserve_scroll_on_compute keeps the
same top entry in view, the way Material UI already does when geometry
changes without the list changing.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[glui] [ozone] Mouse Navigation Improvement Suggestions

1 participant

@KrisEnigma