mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-08-26 03:57:16 +02:00
81 lines
1.9 KiB
Markdown
81 lines
1.9 KiB
Markdown
# Settings and data context
|
|
|
|
Inspect `Config`/settings classes and current UI before using these names; this list records important settings/concepts encountered during prior work.
|
|
|
|
## Band / station settings
|
|
|
|
Important concepts have included:
|
|
|
|
- `MYQRGFirstCat`;
|
|
- `MYQRGSecondCat`;
|
|
- manual station band information;
|
|
- current/actual QTF;
|
|
- known-active bands;
|
|
- selected/current QRG.
|
|
|
|
Band-dependent features must use the correct category/station context.
|
|
|
|
## Antenna / path settings
|
|
|
|
Important concepts have included:
|
|
|
|
- `actualQTF`;
|
|
- `antennaBeamWidthDeg`;
|
|
- maximum QRB;
|
|
- AirScout/path-analysis settings.
|
|
|
|
Missing QRB/QTF must remain unknown, not numeric zero.
|
|
|
|
## UI settings
|
|
|
|
Persisted UI behaviour has included:
|
|
|
|
- dark mode;
|
|
- map/path-analysis visibility;
|
|
- filters/reachability controls;
|
|
- column visibility;
|
|
- divider/layout state where implemented.
|
|
|
|
Do not reset persisted user choices as an incidental effect of a feature change.
|
|
|
|
## Logging / worked persistence
|
|
|
|
Worked information is persisted and updated through multiple input paths.
|
|
|
|
Before changing one path, compare semantics across:
|
|
|
|
- DB load on startup;
|
|
- simple/manual log integration where present;
|
|
- UCXLog/DXLog;
|
|
- Win-Test;
|
|
- other current logging inputs.
|
|
|
|
The goal is one worked-state interpretation regardless of source.
|
|
|
|
## Chat/message automation
|
|
|
|
Configuration has included:
|
|
|
|
- beacon/autoanswer enablement;
|
|
- beacon defaults;
|
|
- message limits/timers;
|
|
- category-specific communication.
|
|
|
|
Do not duplicate timers or create per-feature scheduling that bypasses the shared safety model.
|
|
|
|
## Connection state
|
|
|
|
Connection-state UI must reflect actual ON4KST connection lifecycle.
|
|
|
|
Any new state enum/property should have a clear owner and thread boundary.
|
|
|
|
## Persistence rule
|
|
|
|
Do not change persisted keys/schema/semantics simply to make new code easier.
|
|
|
|
If a schema/key migration is required:
|
|
|
|
1. explain current and new format;
|
|
2. describe backward compatibility;
|
|
3. ask for approval before implementing.
|