[Feature]: Hotkey to queue the hovered track (press Q on any track row)

[tsibog]

Is there an existing feature request for this?

• I have searched the existing issues

Problem or Motivation

Building a queue while browsing is mouse-heavy: every track requires right-click → context menu → "Play Next" / "Add to Queue". When queueing up many songs from search results, playlists, or home shelves, that's a lot of clicking.

Related but distinct from #52 — that one asks for global (system-wide) shortcuts; this is an in-app hotkey while browsing.

Proposed Solution

A keyboard-first flow: target any track row and press Q to add it to the queue.

• Works anywhere a track row is rendered (search, playlists, home sections, artist pages, history)
• Brief visual confirmation on the row so you know it landed — and the feedback distinguishes whether the track was added next vs appended to the end
• Symmetry in the Queue panel: target a queued track and press Q to remove it

Targeting (which row Q acts on):

• When keyboard focus is on a track row, focus takes precedence over the mouse hover — so keyboard-only navigation is predictable and doesn't depend on where the cursor happens to sit
• When nothing is focused, fall back to the hovered row
• The shortcut is ignored while typing in a search field (or any text input), so Q types a literal "q" as expected

Open questions to confirm before implementing:

• Should Q "add to queue" (append at the end) or "play next"? (Feedback will make the resulting behavior explicit either way.)
• Should the key be configurable?

I have a working implementation of this on my fork and would be happy to open a PR if there's interest — filing this first since a hotkey is more opinionated UX than my other PRs (#363/#364/#365) and I'd like to confirm the interaction fits the app's direction before submitting.

Alternatives Considered

• A hover-visible inline "+" button on each row — more discoverable, but adds visual noise to every row and is still mouse-driven
• Drag-and-drop onto the queue panel — complements this, but doesn't solve the many-tracks-fast case
• Only offering it via the context menu as today — the status quo this tries to improve

Feature Area

UI / Visual

[tsibog]

Should keyboard focus take precedence when it points to a different track than the mouse hover? Defining that would make the shortcut predictable for keyboard-only use. The shortcut should also be ignored while typing in a search field, with brief feedback showing whether the track was added next or appended.

Yeah, I think it should. All good points. Will update the description.