Expose mouse wheel events

[ThatXliner]

Mouse wheel events silently dropped in both GL and crossterm backends

Description

Both of bracket-lib's backends (native GL/GLFW and crossterm) catch-all scroll wheel events without relaying them, making it impossible to implement mouse-wheel-scrollable UI panels (e.g. console output, inspector, or logs).

Affected code

Native GL backend —

bracket-lib/bracket-terminal/src/hal/native/mainloop.rs

Line 304 in ce9124a

_ => {}

Note: WindowEvent::MouseInput (line 262) is handled for button clicks (Left/Right/Middle), but scroll wheels fire a separate WindowEvent::MouseWheel variant in glutin, not MouseInput. On some GLFW configurations scroll may also emit MouseButton::Other(4/5) through MouseInput, but this is platform-dependent and not a reliable path for scroll support.

Crossterm backend —

bracket-lib/bracket-terminal/src/hal/crossterm_be/main_loop.rs

Line 77 in ce9124a

_ => {

crossterm::event::MouseEventKind::ScrollUp and ScrollDown variants fall through the wildcard on the MouseEventKind match.

Desired behavior

Scroll wheel events should be exposed through BTerm or the input state so that downstream consumers can query accumulated scroll delta each frame. For example, an i32 field like mouse_scrolled: i32 on MouseCursor or InputState that resets to 0 after being read, or a scroll_delta field on BTerm.

Workaround

Upstream currently requires patching the dependency or forking. In our project we use Up/Down arrow keys to scroll UI panels instead.

---

Yes this description was mostly generated by AI, but if I were to manually write this, I would have never known about the relevant code in question. I need this functionality for my project