mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-11-11 15:32:28 +01:00
Claude
86289609e8
Forgotten beacons kept filling the chat while nobody was at the station. - The two enable switches are session state now: they start off, are never read from preferences.xml and are always stored as "false", so neither a stored switch nor an older release reading a newer file can start a beacon. The in-code default was "on" and started a beacon whenever the file was unreadable or had no <beaconCQ> block. - The minimum interval rises from 1 to 5 minutes; the bundled template ships 10 instead of 1. Smaller stored values are raised when the timer is scheduled. - BeaconFrequencyGuard switches a beacon off once a logger-reported transceiver frequency lies more than 2 kHz from the one reported when the beacon was switched on. UCXLog RadioInfo and Win-Test STATUS feed it wherever they already set MYQRG/SECONDQRG. Without SO2R the single radio stands for both categories, with SO2R each radio for its own. Manual (DE/EN), changelog, website and PROJECT_CONTEXT updated. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NJ1tUJVmWChD9V5Pg7uH8X
53 lines
2.9 KiB
Markdown
53 lines
2.9 KiB
Markdown
# Live Beacon Control Design
|
|
|
|
Freigegeben von Marc am 2026-11-04.
|
|
|
|
> **Teilweise abgelöst durch Issue #171 (2026-11-11):** Die Beacon-Zustände werden nicht mehr
|
|
> gespeichert und nicht mehr beim Profilstart geladen; jede Sitzung beginnt mit „aus“. Das
|
|
> Mindestintervall beträgt fünf Minuten, und eine TRX-Frequenzänderung über 2 kHz schaltet die
|
|
> Beacon ab. Der aktuelle Stand steht in `docs/PROJECT_CONTEXT.md` unter „Autoanswer / Beacon“.
|
|
> Alles Übrige in diesem Dokument gilt weiter.
|
|
|
|
## Ziel
|
|
|
|
Die beiden Beacon-Aktivierungsschalter wirken in der laufenden Sitzung sofort. Der gemeinsame
|
|
Beacon-Timer bleibt bestehen und liest bei jedem Lauf die aktuellen Zustände. Der Beacon-Chip
|
|
im Hauptfenster zeigt den zusammengefassten Zustand und kann die aktuell nutzbaren Beacons
|
|
gemeinsam ein- oder ausschalten.
|
|
|
|
## Verbindliches Verhalten
|
|
|
|
- Die gespeicherten Beacon-Zustände werden beim Profilstart geladen.
|
|
- Ein Klick auf eine Beacon-Checkbox wirkt sofort im Speicher und damit beim nächsten
|
|
regulären Timerlauf.
|
|
- Aktivieren sendet nicht sofort und startet den Timer nicht neu.
|
|
- Erst **Einstellungen speichern** schreibt die Zustände in die Profil-XML. Ohne explizites
|
|
Speichern gilt die Änderung nur für die laufende Sitzung.
|
|
- Beacon-Text und Intervall bleiben normale Settings-Entwurfswerte. Das Intervall startet den
|
|
Timer erst beim Anwenden neu.
|
|
- Der Status-Chip zeigt `off`, `1/2` oder `on` für die aktuell nutzbaren Kategorien.
|
|
- Sind alle nutzbaren Beacons aus, aktiviert ein Chip-Klick alle nutzbaren Beacons. Ist
|
|
mindestens eine nutzbare Beacon an, deaktiviert der Klick alle nutzbaren Beacons.
|
|
- Bei deaktiviertem zweiten Chat schaltet der Chip nur die Hauptkategorie und verändert das
|
|
gespeicherte Flag der zweiten Kategorie nicht.
|
|
- Chip und geöffnetes Settings-Fenster zeigen denselben beobachtbaren Zustand.
|
|
- Nur der Beacon-Chip wird anklickbar. Andere Thread-Status-Chips bleiben reine Anzeigen.
|
|
|
|
## Unveränderte Grenzen
|
|
|
|
- Beide Kategorien behalten eigene Aktivierungsflags und Texte.
|
|
- Der zweite Beacon-Versand setzt weiterhin einen aktivierten zweiten Chat voraus.
|
|
- Nachrichtenvalidierung, TX-Warteschlange und ON4KST-Protokoll bleiben unverändert.
|
|
- Mindestintervall, gemeinsamer Timer und Intervall-Persistenz bleiben unverändert.
|
|
- Profilzustände werden nicht miteinander vermischt.
|
|
|
|
## Technischer Ansatz
|
|
|
|
Die vorhandenen `ChatPreferences`-Getter und -Setter bleiben die kompatible Schnittstelle,
|
|
werden für die beiden Aktivierungsflags aber auf thread-sichere beobachtbare Werte gestellt.
|
|
Der Settings-Tab liest diese Werte als Compose-State und schreibt Aktivierungen direkt durch
|
|
den Controller. Der Controller veröffentlicht nach jeder manuellen Umschaltung einen
|
|
zusammengefassten `MyBeacon`-Status. `BeaconTask` meldet nach einem Timerlauf ebenfalls genau
|
|
diesen zusammengefassten Status. `ThreadStatusButtons` erhält eine optionale Aktion pro
|
|
Quelle; die Anwendung registriert sie nur für `MyBeacon`.
|