Allow users to select which monitor to display the overlay on

[LoricAndre]

Is your feature request related to a problem?
The overlay doesn't show up on the monitor I'm looking at, which makes it pretty useless.

Describe the solution you'd like
Let me choose which monitor to display on, ideally either a fixed one or the "active" one (the one where the cursor is one ? Active window ?)

[Roddygithub]

Implemented and merged in #26 — thanks for the suggestion!

The overlay now has a Monitor setting with:

Value	Behaviour
Primary (default)	first monitor reported by the compositor
Cursor monitor	follows whichever display your pointer is on
Monitor 0 – Monitor 3	pinned to that specific display

It's in Vencord → Plugins → VesktopVoice Overlay → Monitor, and it takes effect immediately — no restart needed. Selecting an index wraps around if you have fewer monitors than that, and unknown/missing values safely fall back to Primary.

Please try it on your setup and let me know how it behaves — especially whether Cursor monitor tracks the way you'd expect when moving between displays. Happy to adjust.

[Roddygithub]

A follow-up review found that the original implementation did not consistently apply runtime monitor changes. A fix is being prepared in PR #30 with regression coverage for live settings updates and cursor tracking.

[Roddygithub]

The correction is merged in PR #30. Settings updates now use the current runtime selection, invalid monitor values are rejected, and Cursor mode checks for target changes every 350 ms. Cursor targeting is explicitly best-effort on Wayland because GDK cannot query global pointer coordinates across applications. This machine has only one active output, so multi-monitor movement and cursor-follow could not be live-validated; the issue remains open for a retest on a multi-output setup.

[Roddygithub]

PR #30 is merged. The merged candidate passed Rust fmt/clippy/tests (44), release build, plugin lint/tests (25), and two-output fixed-monitor runtime checks using Hyprland HEADLESS output(s) that GTK/GDK exposed as two monitors. Monitor 0/1 selection, index wrapping, strict invalid-value rejection, live settings, mode transitions, and hide/show/clear/replay worked.

Hotplug validation exposed a release-blocking failure. During an add → use → remove → re-add cycle with the candidate overlay targeting a HEADLESS output, the candidate process SIGSEGV'd at 2026-10-08 03:13:45 CEST, shortly after the output was recreated and topology/settings activity continued. The core backtrace faults in GTK4 during Wayland display dispatch via libffi. The exact triggering phase (removal, re-add notification, or subsequent monitor update) is not isolated; hotplug is not safe to claim validated. Reproduction: create one temporary output with hyprctl output create headless; send a valid settings message selecting index:1 to the overlay settings socket and make a synthetic snapshot visible; remove the reported output with hyprctl output remove NAME; recreate it and continue the monitor update sequence. The candidate crashed during this cycle. Physical dual-monitor hardware was unavailable.

Cursor/Active remains best-effort: GDK did not reliably resolve the pointer to a surface on the other output, even when Hyprland reported cursor coordinates there. No source changes or release were made. The original v1.3.0 service was restored and is healthy. Keeping issue #21 open pending hotplug crash root-cause work and retest.

[Roddygithub]

The experimental monitor-selection remediation from PR #30 was reverted from main before release; it was never shipped. Fixed multi-output/headless selection showed promise, but hotplug testing exposed candidate SIGSEGVs in GTK/Wayland dispatch and the root cause remains unresolved (project lifecycle vs. upstream GTK/GDK/Wayland). The installed stable v1.3.0 is unaffected. Further monitor-remediation work is deferred pending stronger diagnostic evidence or demonstrated multi-monitor demand. Issue remains open.