Feature: Message Creator, QSY Monitor, and Message Popups (WSJT-X special messages)

[Reid-n0rc]

Summary

Bring WSJT-X's special-message workflow to FT8AF: a Message Creator for composing canned/QSY-request messages, a QSY Monitor that surfaces QSY requests aimed at us, and Message Popups that alert the operator when a calling station sends one of these messages.

Reference: WSJT-X User Guide — Message Creator, QSY Monitor, and Enable Message Popups

Background — what this feature is in WSJT-X

WSJT-X lets an operator invite a QSO partner to move to another band or mode (common during contests / grid activations), or send a short "canned" message, all with a couple of clicks. It has two visible parts plus a popup layer:

• Message Creator — a small window (opened from the View menu) with four tabs: HF, VHF, EME, and General. On the band/mode tabs you pick a band, mode, and the kHz portion of a frequency to build a QSY request; the General tab offers a set of canned short messages. Send Message queues it for the next transmit slot (it auto-enables Tx) and addresses it to the callsign currently in the DX Call field.
• QSY Monitor — a window that watches decodes for QSY requests directed at the operator and displays the requested band/mode/frequency.
• Enable Message Popups — when on, an incoming special message (canned text or a QSY request aimed at you) raises a popup so the operator notices it even if they aren't watching the decode list.

Setup note: the operator's IARU Region must be set for the band plans / QSY frequencies to be correct.

On-air encoding

These messages ride inside standard FT8 frames — there is no new protocol on the wire:

• Canned / QSY-request text is carried as free text (i3=0, n3=0, 13-char limit), which FT8AF already packs and decodes (GenerateFT8.packFreeTextTo77, Ft8Message i3/n3 parsing).
• So the work is mostly UI + message templating + decode-side recognition, not DSP.

Proposed scope for FT8AF

Break this into shippable pieces (each its own PR per the workflow):

1. Message Creator UI

   • New screen/dialog to compose a message addressed to the current DX call.
   • Tabs for band/mode QSY requests (build the free-text string from band + mode + kHz) and a list of canned messages (General tab).
   • "Send" hooks into the existing transmit queue and enables Tx for the next cycle.
   • Gate QSY-frequency options on the configured IARU Region.

2. Decode-side recognition + QSY Monitor

   • Detect incoming free-text messages that match a QSY-request / canned-message pattern and are addressed to our callsign.
   • A QSY Monitor list showing sender, requested band/mode/frequency, and timestamp.
   • Optional: one-tap "accept" that retunes the rig (CAT) to the requested frequency/mode.

3. Message Popups

   • Setting to enable/disable popups.
   • When enabled and a matching message is decoded for us, raise a popup/toast (reuse ToastMessage / a dialog) with the message and, for QSY requests, a shortcut to retune.

Open questions

• Which canned-message set do we ship (mirror WSJT-X's General tab, or a trimmed mobile-friendly list)?
• How far do we go on auto-QSY via CAT vs. just displaying the request?
• Exact free-text template WSJT-X uses for QSY requests — confirm against the reference so we interoperate with real WSJT-X stations.

Testing

Per project rules, every new code path needs a unit test. Extract the message-templating and decode-recognition logic into plain internal/top-level functions (e.g. a buildQsyMessage / parseQsyRequest) and unit-test the string building and pattern matching directly; keep Compose/UI as thin wrappers.