mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-10-19 22:02:57 +02:00
4642d658a3b40483882e7a86e413d8c31b7f882b
36
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Rsclub2_2andClaude
|
d38b385166 |
Open menu row menus flush under the bar (#143)
Material3's DropdownMenu clamps every popup to 48dp below the window's top edge (MenuVerticalMargin in its position provider); the margin is applied after the offset parameter and the provider is not replaceable, so the in-window menu bar's menus all opened with a visible gap hanging below the bar. Replace them with a plain focusable Popup in MenuDefaults styling and an own position provider that puts the menu directly under its anchor, flipping above only when there is no room below. The anchor box takes the full bar height so the menu starts at the bar's bottom edge, not at the centred title text. Claude-Session: https://claude.ai/code/session_01BegdsGSNNxKR6VPNPNvfoc Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Fable 5
|
a28abe1591 |
Update repository URLs to HamRadioOnline organisation (#142)
* Move remaining references to the HamRadioOnline organisation The repository moved from praktimarc/kst4contest to HamRadioOnline/kst4contest. Document the move in the German and English changelog, point manuals, README, website, AUR packaging and the version-feed tooling at the new address, and keep accepting pre-move release URLs in the update-feed validator because published feeds still carry the old owner. Personal identities (Ko-Fi account, contact e-mail) stay unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WFGQ7wkSPo21itLMHPi8Yw * Lowercase the owner in the generated Flatpak Pages URL GITHUB_REPOSITORY_OWNER is now the mixed-case HamRadioOnline, and the next build would write that spelling into the published flatpakrepo and flatpakref files. Hostnames are case-insensitive, but the published metadata should match the documented lowercase address. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WFGQ7wkSPo21itLMHPi8Yw * Build the Flatpak against org.freedesktop.Platform 25.08 Runtime branch 24.08 is end-of-life and no longer receives security updates, so every flatpak update now prints an EOL warning. 25.08 is the current supported branch on Flathub. The app bundles its own Java runtime, so the platform bump only changes the base libraries. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WFGQ7wkSPo21itLMHPi8Yw --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Opus 5.5
|
e0c1c6b6d4 |
One chat-frame flow for live and history messages (#105) (#139)
Second slice of making MessageBusManagementThread testable. The CH (live) and CR (history) chat-frame branches of processRXMessage23001 were near copies; they are now one processChatFrame(fields, live), with behaviour unchanged. - InboundChatFrame, ChatRoute and classifyRoute: where a message belongs (public, to me, from me, between others), pure. - ChatMessageEffects and decideChatFrameEffects: what a message triggers (sounds, //BELL, //VER reply, auto-answer, directional tick, in-angle flag, DX cluster spot), pure. History frames trigger nothing but the flag. - The four live/history differences are kept on purpose: frequency detection before routing (live) or after publishing (history), effects for messages to me, tick and spot between others, AirScout info on the SERVER sender. - MessageBusManagementThreadChatFrameTest pins both branches through the real thread, including the frequency order on directed frames and the spot entry; ChatFrameDecisionTest covers the pure functions. - Spec: docs/superpowers/specs/2026-10-16-message-bus-second-slice-design.md Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Opus 5.5
|
5b7c774f5f |
SO2R: two radios in one instance (#46) (#137)
* Spec: SO2R with two radios in one instance (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Plan: SO2R implementation (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Move the rotator command rules into RotatorControl (#46) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> * Store the SO2R switch, the second Win-Test station and rotator 2 (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Route frequency reports to radio 1 or 2 (#46) Add the RadioSlot enum (FIRST, SECOND) with its QRG and QTF targets, and the pure RadioSlotRouter that decides per RadioInfo packet and per Win-Test station which radio a report belongs to. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Send RadioInfo of radio 2 to SECONDQRG when SO2R is on (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Send Win-Test STATUS of the second station to SECONDQRG when SO2R is on (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Run a second PSTRotator for radio 2 with SO2R (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Start rotator 2 only while an ON4KST session runs (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Settings for SO2R, the second Win-Test station and rotator 2 (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Turn antenna 2 and show QTF2 with SO2R (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Make the SO2R switches observable so Apply shows them (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Document SO2R (#46) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Refuse clashing PSTRotator ports in both directions (#46) Writing either port now checks same-or-adjacent against the drafted value of the other; rotor 1 is only checked while SO2R and rotor 2 are on. Also fixes a misplaced Javadoc, stale WinTest parseStatus Javadoc, docs wording and removes an unused import and dead comment. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Remove the executed SO2R plan (#46) The plan's content lives on in the commits, the spec and PROJECT_CONTEXT. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Opus 5.5
|
feb4b4e2c9 |
Open secondary windows on the main window's screen (#59) (#135)
* Open secondary windows on the main window's screen (#59) Every Compose window but the main one went to the platform's default position, which on a multi-monitor desk is the primary screen - the station map could open on a monitor that was switched off. They now open centred on the screen the main window is on, with their size clamped to that screen's usable area (insets considered). A window the operator moved during the session reopens there, as long as its title bar can still be grabbed on a connected screen; otherwise it falls back to the main window's screen. The position lives only in the window's host and is never persisted. ComposeAlert dialogs and the profile picker are centred the same way once the main window exists. The rule is a pure function (WindowPlacement) with 18 unit tests; the AWT side (WindowPlacementOnScreen) only reads the screens and the main window's bounds on the event thread. The clamped opening size of a secondary window is not written back, so the stored size survives a smaller screen. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Track window moves reliably and keep remembered windows on screen (#59) Review fixes for the window placement: - Once a window has left the tolerance around its opening position, every later position is remembered. Before, the anchor was never re-set, so dragging away and back to near the opening spot left the stale far position remembered. - A window the host did not place (opened before the main window exists) only trusts its anchor once two consecutive reports lie within the tolerance, so a provisional position followed by the window manager's placement jump is no longer taken as the operator's move. - A remembered position is shifted the least distance that puts the (clamped) window wholly inside the usable area of the screen holding its title bar, as the KDoc promised. The move rule moves into a pure MoveTracker with 5 tests; WindowPlacement gains keptWithin and 2 more tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Keep window positions across restarts as an opt-in; fit windows to small screens (#59) A new GUI tab option, off by default, keeps the position the operator last moved each window to, the main window included. It is stored per window with the bounds of the screen it was on, written by the layout autosave, and restored only when a screen with exactly those bounds is connected again; otherwise the session rule applies. Only operator moves are stored, never window manager nudges, so a restored window cannot drift. An open window that rests on a screen too small for it is now cut down to that screen's usable area, and the station map's 900x600 minimum is capped to the smallest connected screen, so 640x480 monitors stay usable. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Never store a size or position the host fitted a window to (#59) The cut-down to a small screen was written back as the stored size (main window via onResized, others via the tracker) and counted as an operator move. The host now records its own fit: that size is not written back, and that position re-anchors the move tracker instead of being stored. A main window opened at a stored position skips its opening size like the other windows, since it may be clamped too. The opt-in gate moves into PreferencesWindowPositionMemory, with tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Match the fit echo with tolerance and consume it once (#59) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Opus 5.5
|
92c2576a81 |
Path analysis: own ground height ASL and highest point of the remote locator square (#133)
* Path analysis: own ground height ASL and highest point of the remote square Two new settings in the path-analysis section of the Station tab: - Own ground height ASL (stn_pathAnalysisOwnHeightAslMeters). Empty keeps the elevation model value at the own locator centre; a value from -500 to 9000 m replaces the elevation of the first profile sample. The antenna height AGL is still added on top. The field commits on Enter or focus loss into the settings draft and reports a refused entry; it keeps the operator's spelling while that names the drafted number, because the draft is Compose state and would otherwise swap "25" for "25.0" under the cursor right after Enter. - Target station on the highest point of its locator square (stn_pathAnalysisDxHighestPointInSquare, on by default). The remote square is sampled on a 5 x 5 grid of cell centres in one batched request against the Open-Meteo provider, the highest sample becomes the path end with its position and elevation. LocatorHighestPointResolver caches the result per locator for the session and backs off five minutes after a failure (failure list pruned and bounded); the analysis then falls back to the square centre and that result is not kept. Both settings are drafted like the other path-analysis settings and take effect with Apply/Close or Save; the reachability service reads the stored values only. The lookup runs on the reachability thread only. Building a request peeks the resolver cache without blocking, so a cached square moves the endpoint right away. The calculation key now includes the own height and the remote ground elevation at full precision, and the switch, so changing either recalculates. Also assign the result of sanitizeEffectiveEarthRadiusFactor in the PathAnalysisRequest constructor; it was called and dropped. No behaviour change: the sanitizer is the identity for valid factors, and the analysis service sanitizes again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Document own ground height and highest-point setting of the path analysis Changelog v1.50 (New), configuration and features pages in English and German, and the terrain section of PROJECT_CONTEXT. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Opus 5.5
|
f17ae0905f |
Settings take effect with Apply/Close or Save (#134)
* Add a settings draft that holds edits until they are applied The settings window is to stage its edits and apply them with Apply/Close or Save instead of writing each one at once. SettingsDraft holds one pending change per setting, reads through to the stored value, and on apply writes everything first and then runs each effect key once, in the order the settings were first changed. Form.committed registers its typed entry with the draft so a click on Apply cannot lose it. The spec explains the order and the settings that stay immediate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Stage the settings tabs' edits and apply them with Apply/Close or Save Every tab state now reads through the window's draft and stages its edits there instead of writing ChatPreferences: Station (all but the login credentials), Log synch, TRX synch, Airscout, Notification, Shortcuts, Beacon, Message handling and GUI (all but the language). The lists stage their roster, the committed fields stage what their rule accepts. Effects stay attached to their settings. The Win-Test listener and the DX cluster server share one effect for switch and port that brings the running service in line with the applied state, so applying both restarts it once, on the new port. The own-QRG follower runs once for both sources. Apply/Close applies and closes, Save applies and writes, Connect applies before it connects, so the session uses what the tabs show. A field that refuses its entry on the way stops the button with the reason shown. Immediate as before: the login credentials, the language, the colours, the file chooser, the test spot and the profile and worked-database actions. Number fields keep the typed text while the staged value comes back as Compose state; otherwise "1" became "1.0" before the next key. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Ask about unapplied settings when the window is closed Closing the settings window with its X, or through the Windows menu, while edits wait in the draft now asks: apply them, discard them, or go back to the window. Without pending edits the window closes as before. Fields and list rows still holding a typed entry are committed first, so an entry typed just before the X counts. The request only sets Compose state; the window decides on its next frame, so nothing waits on the event thread. A close from outside -- a profile switch, the shutdown -- discards the draft: the preferences it belongs to are about to be replaced. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Document that settings take effect with Apply PROJECT_CONTEXT records the draft and what stays immediate, the changelog gets one entry under v1.50, and the configuration manual no longer says that settings take effect while they are edited. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Repair stored settings once before the settings window is built The fallback band of the DX cluster was repaired to 144 inside a getter that runs during composition, and the Win-Test broadcast address was auto-detected in a tab state's constructor. Both wrote ChatPreferences past the draft at a moment nobody could see. repairStoredSettings now does both once, before any tab is built; the tab states only read. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Ask before a profile switch or exit, and check fields before applying A profile switch and the exit dropped pending settings edits silently. They now go through SettingsWindow.settleThen: with edits pending, the window is raised and asks Apply / Discard / Back; Apply applies them to the profile still in force, Back cancels the switch or the exit. The question is Compose state and the continuation is posted from the dialog's callback, so the event thread never waits. Without pending edits both go on at once. Fields are checked before anything is applied: a field still showing text that does not parse, or that its rule refuses, refuses the apply and is named in the notice, so the valid edits stay pending and Discard is still possible. This covers number fields and the guarded external-interface fields, which used to let Apply go ahead with the last valid value. Every write and effect of an apply now runs on its own; failures are collected and reported, a failed write stays pending and skips its effect, and Save still writes the file when only an effect failed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Check every drafted setting with a real draft, and rename write-through tests DraftedSettingsTableTest walks every drafted setter of every tab with a real SettingsDraft: unchanged after the edit, changed after apply, unchanged after discard. The tab tests run with a draft that applies at once and cannot tell a drafted setting from one that bypasses the draft. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Document the question on switch and exit, the field checks and the repairs Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Decide the pending-settings question on the event thread, never trap The question is now a SettingsQuestion decided in settle() on the calling event thread instead of in the settings window's next frame, so an exit from the main window does not depend on frames of a minimised settings window; the window is raised and restored before the dialog is needed. While a question is open, further requests are ignored: an X no longer replaces the continuation of an exit or switch with a plain close. Each continuation of settleThen runs at most once. A field holding text it refuses no longer traps the operator: the X, the switch and the exit show the question anyway, with the reason, Apply disabled and Discard and Back available. The apply-failure notice keeps the technical detail out of the sentence, in parentheses after a translated one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Opus 5.5
|
4679c708bc |
Fix UDP listener defects (#115) (#122)
* fix: let ReadUDPbyUCXMessageThread own its DatagramSocket so interrupt() closes it (#115) The field `socket` was a java.net.Socket that was never assigned; the real DatagramSocket lived in a local variable of run(). interrupt() therefore closed nothing and terminateConnection() would have thrown a NullPointerException. The receive loop kept running in two-second timeout steps until the user-disconnect flag was set. The field is now the DatagramSocket, run() binds it when no pre-bound socket was handed in, the loop ends on the interrupt flag or a closed socket, and both interrupt() and terminateConnection() are null-safe. A package-private constructor accepts a pre-bound socket so loopback tests can listen on an ephemeral port; the public constructor used by ChatController is unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix: stop ReadUDPbyUCXMessageThread truncating datagrams after a short packet (#115) A DatagramPacket keeps the length of the last datagram it received, so a long RadioInfo packet following a short one was cut to the short one's length and failed to parse. The length is reset to the buffer size before every receive, the same way ReadUDPByWintestThread does it. The loopback test sends a short and then a long packet on port 0 and checks that both frequencies arrive. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix: give PstRotatorClient's port constructor a callback, decode AirScout as UTF-8 (#115) The explicit-port constructor left the thread-status callback null, so start() and the first received packet threw an NPE; the default constructor now delegates to it. The AirScout listener decoded replies with the platform charset although the inquirer sends UTF-8. PROJECT_CONTEXT listed PSTRotator as TCP; the client speaks UDP. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix: decode UCX datagrams as UTF-8 and tighten the interrupt test (#115) Review follow-up. UCXLog sends UTF-8 XML, but the listener decoded with the platform charset before handing a String to the parser, so the XML header's encoding was ignored. The port-in-use fallback now sets its receive timeout before the first receive(). The interrupt test waits 1 s, below the 2 s receive timeout, so it fails if interrupt() stops closing the socket; the QRG latches now count one value each. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Fable 5.1
|
f2b0fdd5b4 |
Write SpotBugs reports and publish static analysis on pull requests (#110) (#114)
* build: write SpotBugs XML and HTML reports (#110) The SpotBugs tasks had no report configured, so findings went to stdout only and, with ignoreFailures, scrolled past unread. Every SpotBugsTask now writes XML (for CI to count) and HTML (for people) to the plugin's default location, <module>/build/reports/spotbugs/main.{xml,html}. ignoreFailures stays; the build still passes with findings present. Fixes #110 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: run PMD and SpotBugs on pull requests and publish the reports (#110) The compile job runs pmdMain and spotbugsMain after compiling (report only: both tools have ignoreFailures, a crash of a tool still fails), counts <violation> and <BugInstance> elements per module from the report XML into the job summary, and uploads */build/reports/pmd and */build/reports/spotbugs as the static-analysis artifact for 14 days. A missing report prints "no report" without failing the step. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: name the PMD and SpotBugs report files and the CI artifact (#110) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Fable 5.1
|
89d37e62e1 |
Give beta DEB and RPM packages a pre-release number (#113) (#116)
* build: give beta DEB and RPM packages a pre-release number (#113) composePackageVersion is the package version of every Compose target format, so an RPM or DEB built from a beta tag carried exactly the version of the following stable one. dnf, rpm -U and dpkg refuse to replace a package by one of equal version, so a beta user could not move to the stable. Keep the version and tell the packages apart by the package release number, following the Fedora pre-release convention: the new Gradle property linuxAppRelease is passed to jpackage as --linux-app-release (Compose LinuxPlatformSettings.appRelease) and defaults to 1. beta-v1.50.0-beta-001 -> 1.50.0-0.beta.001 beta-v1.50.0-rc02 -> 1.50.0-0.rc02 v1.50.0 -> 1.50.0-1 Everything starting with "0." sorts below "1" for both rpm and dpkg. Nightlies and local builds do not set the property and keep release 1. Fixes #113 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: derive the Linux release number from the tag and verify the tag version (#113) The DEB and RPM jobs now compute the package release from the tag before calling Gradle and pass it as -PlinuxAppRelease: a stable vX.Y.Z tag gives 1, a beta-vX.Y.Z-<suffix> tag gives 0.<suffix> with "-" turned into ".". The result must match [A-Za-z0-9.]+, otherwise the step fails. A workflow_dispatch run from a branch keeps release 1 like the nightlies; nightly-artifacts.yml is unchanged. The test job, which every packaging job depends on, now checks right after the checkout that the X.Y.Z in the tag equals composePackageVersion in gradle.properties and fails with a clear message otherwise, so a mistagged commit fails before an hour of packaging rather than shipping packages whose version contradicts their file name and upgrade order. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: describe the pre-release number of beta DEB and RPM packages (#113) The German and English installation manuals say in the Debian/Ubuntu and Fedora sections that beta packages carry a pre-release number below the stable one, so the stable installs as an upgrade over a beta. The v1.50 changelogs gain the matching "Fixed" entry, and PROJECT_CONTEXT.md records the rule next to the MSI decision. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Fable 5.1
|
2eb1ba22cf |
Windows MSI installer next to the portable ZIP (#61) (#111)
* build: configure the Windows MSI installer in the Compose windows block (#61) Add the jpackage/WiX options for a per-user MSI next to the existing icon: a fixed upgradeUuid so Windows Installer replaces an installed KST4Contest instead of installing side by side, a Start menu group and desktop shortcut, no UAC prompt, and a directory chooser. The portable ZIP (createDistributable) is unaffected; the MSI is produced only by the tagged-release workflow. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: build and attach a Windows MSI installer for tagged releases (#61) The Windows job of tagged-release.yml now runs packageMsi after the portable ZIP, renames the result to KST4Contest-<tag>-windows-x64.msi (consistent with the other platforms; the ZIP keeps its praktiKST name) and uploads it as the windows-msi artifact, which the release job downloads and attaches next to the ZIP. The nightly workflow stays ZIP-only because a nightly MSI would always carry the same version. The website download data (downloads.js, beta.js) gets an MSI card that is shown only when the release actually has that asset, so the page never links to a file that does not exist for an older release. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: describe the Windows MSI installer next to the portable ZIP (#61) The German and English installation manuals list the MSI in the package table, describe both Windows forms (installer: per user, Start menu entry, desktop shortcut, chosen directory, in-place upgrade, removal via the Windows apps list; ZIP: portable) and the shared data directory %USERPROFILE%\.praktiKST, and add the MSI path to the Windows update section. Changelog entries for v1.50 and a note in PROJECT_CONTEXT.md record the fixed upgrade UUID and the tags-only decision. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: build the Windows MSI for stable tags only (#61) A beta MSI would carry the same composePackageVersion as the following stable release. jpackage's MSI upgrade table only accepts strictly higher versions, so Windows Installer would refuse the stable over an installed beta and the tester would have to uninstall first. Betas therefore stay ZIP-only like nightlies; the build, upload and download steps are skipped for beta- tags, and the release action tolerates the missing asset path. Manual, changelog and project context say so. Raised by the Codex review on #111. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Fable 5.1
|
5491cbcf8b |
Test suite cleanup, JaCoCo coverage report and tests before packaging (#62) (#112)
* docs: add the test-coverage design spec (#62) Records the state found for issue #62 (JUnit classes under src/main that never run, test libraries in the shipped app image, dead 2023/2024 scratch tests, no coverage figure), the decisions taken (delete, move to src/test, JaCoCo report-only without a threshold, tests before packaging), what is deliberately left to separate issues, and the definition of done. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test: move the JUnit classes out of src/main and drop the dead 2023 tests (#62) Gradle's test task scans src/test only, so the six JUnit classes under src/main compiled on every build and were never executed. They move to src/test of the module that owns the class under test, keeping their package names: On4KstProtocolTest, On4KstSocketThreadTest and ChatMemberDirectionOpportunityTest within core; Utils4KSTFrequencyTest, FrequencyTextParserTest and ChatPreferencesStationMapVisibilityTest from app-desktop into core, next to the sibling tests that already live there, because they test core classes only. All 26 of them run and pass. The fully commented-out MessageBusManagementThreadFrequencyContextTest is deleted. Eight files under core/src/test/java/kst4contest/test from 2023/2024 go as well: they carry no assertion, five of them annotate a static main() with @Test, which Jupiter never runs, and some write the real preferences file, send real UDP broadcasts or open the real user database when started by hand. The five main() scratch programs under src/main (ReadUDPByWintestThreadTest, PatternMatcherTest, mapTest, RegexTester, locatorUtils/TestLocatorUtils) and MockKstServer, which only an unused import in ChatController still referenced, are removed too. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * build: make JUnit and Mockito test-only dependencies (#62) With no test class left under src/main, the implementation declarations of junit-jupiter-api and mockito-core in core and app-desktop lose their only justification. They put junit-jupiter-api, junit-platform-commons, opentest4j, mockito-core, byte-buddy, byte-buddy-agent and objenesis on the runtime classpath and into lib/app of every app image, Flatpak and installer. The duplicate catalog entries junit-jupiter-api, mockito-core-compile and the mockitoCompile version go with them. Verified: `:app-desktop:dependencies --configuration runtimeClasspath` no longer lists any of the seven artifacts. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: state that test failures fail the build and tests live under src/test (#62) AGENTS.md and docs/PROJECT_CONTEXT.md still said the build configuration had allowed test failures to pass. That was true of the Maven build; under Gradle a test failure fails the build, and only PMD and SpotBugs run with ignoreFailures. Both documents now say so, note that test classes live under src/test only and that JUnit and Mockito are test-only dependencies, and keep the rule to read the test-result XML rather than the exit code. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * build: add a JaCoCo coverage report (#62) The jacoco plugin is applied to every module from the root build with the tool version held in the catalog. jacocoTestReport now depends on test and writes XML and HTML per module; a root task jacocoAggregatedReport merges core and app-desktop into build/reports/jacoco/aggregated/ (XML plus HTML). i18n-generator is excluded: it is a build tool and its coverage says nothing about the shipped application. Kotlin classes are counted, because the Kotlin plugin adds its output to the main source set the report reads. Report only, on purpose. There is no jacocoTestCoverageVerification and no threshold: a minimum set at today's number would trip on the next unrelated change, and one set at a target would fail every build until tests exist for the number's sake. The figure is published so it can be read when deciding what to test next; the reasoning is in docs/superpowers/specs/2026-10-11-test-coverage-design.md. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: run the tests before packaging and publish coverage (#62) The nightly and tagged-release workflows built seven package formats from commits nobody had tested on the way: pr-compile-check.yml runs the suite for pull requests only, and main can be pushed to directly. Both workflows now carry a copy of that test job, including the libgl1 step and the XML-based summary, and every packaging job declares `needs: test`. Copied rather than factored into a reusable workflow on purpose: the comments in the job explain decisions the packaging workflows should carry with them, and three copies read better than one indirection. build-docs-pdf runs pandoc only and is left alone; publish-flatpak-repo and release-tag are gated through the jobs they already need. The PR test job additionally runs jacocoTestReport and jacocoAggregatedReport once the tests have run (not `if: always()`: a report from an incomplete run would mislead), prints a line/branch coverage table per module and aggregated into the job summary from the JaCoCo XML, and uploads the aggregated HTML report as the coverage-report artifact for 14 days whenever it exists. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: describe the coverage report in the project context (#62) A short paragraph on JaCoCo in docs/PROJECT_CONTEXT.md: report only and why, where the per-module and aggregated reports land, which Gradle tasks write them, that i18n-generator is excluded, how the PR job summary and the coverage-report artifact show the figure, and that the nightly and tagged-release workflows run the tests before any packaging job. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test: round-trip every ChatPreferences field through the XML file (#62) Drive all public single-argument setters by reflection to non-default values, write preferences.xml, read it back and compare every getter. Fields that are not persisted on purpose are listed with their evidence; two real reader/writer gaps (second-category locator, sniffer words) are documented with a BUG marker instead of being fixed here. Two further tests load the bundled template and a legacy file without configVersion. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test: cover the DBController schema migration from older user_version values (#62) Open the seeded template database and hand-built release 1.1 and 1.3 schema fixtures with a DBController and verify that PRAGMA user_version reaches the current level, every column of the current CREATE TABLE statements exists, legacy callsign keys are merged to base callsigns and existing rows and flags survive. A further test proves that reopening an up-to-date database changes neither schema nor rows. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * chore: drop the committed JVM crash report and ignore future ones (#62) hs_err_pid26344.log in the repository root was a HotSpot crash dump that had been committed by accident. It carries no information about the project and must not travel with the sources. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix: drop the dead QSO sniffer word list that corrupted the callsign list on load (#103) ChatPreferences carried a second sniffer list, lstNotify_QSOSniffer_sniffedWordsList, that no UI, no manual and no consumer outside ChatPreferences ever touched. It was still written to preferences.xml as <snifferWords><w>, and the matching reader block was a copy of the <snifferCallSigns> block: it cleared the word list and then added every word, normalised as a callsign, to lstNotify_QSOSniffer_sniffedCallSignList. Any entry that ever reached the word list therefore leaked into QSO monitoring on every load. Remove the field, its accessors, the write block and the read block. A <snifferWords> element in an older preferences file is now ignored like any unknown element; the callsign list and its persistence are unchanged. ChatPreferencesSnifferListTest loads a file that carries both lists and asserts that only the <snifferCallSigns> entry is monitored. The round-trip test loses its exclusion entry for the removed setter. Fixes #103 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix: remove the second-category locator that could never be set (#104) ChatPreferences declared stn_loginLocatorSecondCat with the compiled-in default "jn49fk". Nothing wrote it to or read it from preferences.xml, no settings tab exposed it and no caller ever invoked the setter, so the field always held its default. On4KstConnectionManager.configureMainChat nevertheless compared that default with the station's locator and, with the second chat enabled, raised the warning "ON4KST uses one locator per TCP session. The second-chat locator ... is ignored" whenever the station's locator was not jn49fk, which is practically every installation. ON4KST uses one locator per TCP session by design, so a second-category locator can never become meaningful. Remove the field, its accessors, the comparison and the warning; the rest of configureMainChat is unchanged. The round-trip test loses its exclusion entry for the removed setter. No automated test covers configureMainChat: it is private, works on the manager's private Session and needs a mocked ChatController plus a live socket handshake, so a harness would far exceed the scope of this fix. The compile of core and app-desktop and the shorter exclusion list are the evidence that nothing references the member. Fixes #104 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Fable 5.1
|
4a90ae7d30
|
docs: describe worked-state check for automatic DX cluster spots (#91)
Add the new spot condition to the DX Cluster Server manual pages and the forwarding section of the Features page in German and English, record the fix in the v1.50 changelog, and note the rule in PROJECT_CONTEXT. Fixes #91 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Rsclub2_2andClaude Opus 5.5
|
2a5c89b943 |
Next major release/version1.50 (#89)
* Make DBController work on one database file per instance The controller was a static singleton: an eagerly created static instance opened the root database during class initialization, and both the connection and the path were static fields. A second operator profile in the same process was therefore impossible, and ChatController's own "new DBController()" never opened anything - it silently adopted the eagerly opened root connection. - drop the eager static instance in favour of a lazily created default instance - turn connection and path into instance state - add a constructor taking a database file name relative to the application directory plus a flag whether a missing file is seeded from the bundled template - create additional profile databases empty instead of seeding them: the bundled template carries 3452 foreign callsigns and user_version 0, which would show a new operator foreign data and trigger the full callsign normalization rebuild. The schema is created by the existing table setup. - remember the shutdown hook so closeDBConnection can deregister it; otherwise every profile switch would leave another hook holding a dead connection All SQL statements keep referencing the plain field and are unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Allow preferences and chat controller to be bound to a file set ChatPreferences gains a constructor taking a preferences file name relative to the application directory, so "profiles/OP2/preferences.xml" is as valid as the historic flat "preferences.xml". A missing file is still seeded from the bundled template, which gives an additional operator the same clean defaults a first installation gets. ChatController gains a constructor that passes both relative file names and the seed flag through to ChatPreferences and DBController. The existing constructors delegate to the historic file names, so nothing changes yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Introduce the operator profile model and its registry Adds the descriptor, the path derivation and the registry persistence for operator profiles. Nothing calls them yet, so behaviour is unchanged. The descriptor stores only a shared/own flag, never a path. All file names are derived in OperatorProfilePaths, so a stored path can never drift apart from the flag that produced it. A profile identifier is a stable, file system safe slug assigned once, so renaming a profile never moves a directory. The registry is created lazily. An installation that only has the historic flat layout gets no registry file and no profiles directory; the root profile is synthesised in memory instead. That keeps a single operator installation byte for byte the one it was before, and it keeps a downgrade to an older release a no-op. A missing, unreadable or malformed registry is logged and treated like an installation without additional profiles, never as an error. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Select the operator profile at startup Resolves the active operator profile before the chat controller is built and passes its two file names on, so preferences, layout and worked data follow the profile. The resolution is deliberately quiet for existing installations. With no registry or exactly one profile nothing is asked and nothing is written, so a single operator start is unchanged. Only from two profiles on does a small picker appear with the last used profile preselected, where Enter or a double click starts immediately. A "--profile" argument, or the equivalent system property, skips the picker; an unknown name warns and falls back to the normal selection instead of refusing to start. The startup decision itself lives in OperatorProfileBootstrap and contains no user interface code, so it is covered by headless tests. The window title gains the profile name only when a second profile exists. Command line parsing happens in init() and is kept in a process wide holder, because JavaFX only knows the parameters of the instance it launched itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Release the background resources a discarded runtime owns Several resources outlived a disconnect on purpose, which was harmless while a process ran exactly one session for its whole life. They are now released when the controller itself is closed: - the ON4KST connection supervisor thread, which stopByUser did not touch - the sked reminder scheduler, which had no shutdown at all - the reachability executor, whose shutdown method existed but was never called - the PSTRotator retry scheduler and its pending retry - the map tile proxy, whose stop method existed but was never called, leaving a server socket and a twelve thread pool behind - the station map bridge listeners and its coalescing animation, which would otherwise keep firing into a dead user interface These are real leaks today; they only become visible when a second runtime is built in the same process. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Switch the operator profile while the application is running Splits the teardown out of stop() into a reusable, idempotent shutdownRuntime() and adds File - Switch operator profile..., which tears the current runtime down and builds a fresh one for the selected profile. The new runtime is a new application instance rather than a second start() on the existing one. Many controls are instance fields created once, so reusing the instance would re-parent mounted nodes and register every listener twice. A fresh instance is safe because the class keeps no mutable static state. Closing every window during a switch would end the process under the JavaFX default, so the application takes over the exit decision: implicit exit is turned off, the main window gets an explicit close handler, and every exit path runs through the launcher. That also fixes losing the window layout on exit after a switch, because JavaFX only calls stop() on the instance it launched. The two view timers are now cancelled null-safe; stop() used to dereference them unguarded, which would fail if shutdown happened before they were created. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Manage operator profiles from the settings window Adds a "Profiles" tab, appended last so no established tab position shifts, offering create, duplicate, rename, delete, a switch between shared and own worked stations, and activation of another profile. Duplicating copies the whole configuration except callsign and password. The antenna, locator, layout and integration settings are exactly the work nobody wants to enter twice, while the credentials belong to one operator only. The root profile can neither be deleted nor moved off the common station database, because its files are the installation itself. The login callsign and its raw form now default to empty instead of a real callsign. The XML reader treats an empty element as "not set" and falls back to the field default, so without this change a profile created without credentials would come up carrying the callsign compiled into the defaults - and an operator could transmit under someone else's call. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Document operator profiles Adds a manual section in both languages covering where profile files live, the choice between shared and own worked stations, managing profiles, the startup selection and the --profile argument, switching while running, and the fact that passwords stay in clear text so profiles are not an access boundary. Records the architecture in PROJECT_CONTEXT: lazy registry, derived paths, why an additional profile database is created empty, why the login callsign default is empty, and the constraints of rebuilding the runtime for a switch. Adds a v1.50 changelog entry in both languages including the upgrade notes: no file is moved, and going back to an older release stays possible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Make the terrain profile cache multi operator safe The cache stored a single owner identity in a meta table and dropped the whole TerrainProfileCache table whenever the configured callsign or locator differed from it. With several operator profiles that turns the cache into a permanent miss: every switch between two operators with different locators would discard every computed profile. Entries are separated by owner identity through the primary key already, so the wipe is replaced by an owner table that simply records which identities are in use. A different owner now misses the cache instead of clearing everybody's. The cache also moves out of the worked station database into its own global terrainprofilecache.db. Terrain profiles are pure geometry derived from two locators and a sample count; at a multi operator station both operators share one location, so a per profile copy would only double the traffic against the terrain service. No migration is needed, the new file refills itself, and the old tables stay readable for older releases. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Fail cleanly when the registry path has no directory SpotBugs flagged a null passed to Files.createTempFile: the null check guarded only createDirectories, while the temporary file creation would still have dereferenced it. The path is resolved absolute so this is practically unreachable, but bailing out with a log line is cheaper than the latent NPE. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hpa6bjie5qkeNG62y6FmXm * Code Version 1.50 * Add the in-app update concept for 1.50 Captures the agreed design so it can be handed over later: extended update feed with per-artifact metadata, a build-time package-type marker, a testable check service replacing the blocking call in the ChatController constructor, a non-modal hint suppressed while connected to ON4KST, verified downloads and platform-specific execution. Concept only, nothing implemented yet. Line anchors were verified against this branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HT8R7zTMoQnmJj6dGbaqqf * Use one base font size and a per-profile startup design JavaFX picks a 13px default font on macOS and Linux but 12px on Windows, so labels in fixed-size controls were cut off outside Windows. Both stylesheets now set 12px on the root. Each operator profile now chooses light or dark mode for startup on the GUI settings tab. The Windows menu entries remain a quick switch for the running session. All windows, including the update window and the top candidates list, follow the design, and the main window no longer starts light while the station map starts dark. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Show a drag-to-install layout in the macOS DMG The DMG window now has a background with an arrow from the app to the Applications folder, in the KST4Contest colours. Finder applies the layout through AppleScript; if that fails, e.g. on a headless runner, the script warns and builds the plain DMG as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Use the macOS system menu bar in all windows On macOS the main menus move into the system menu bar and are shared with the secondary windows, so they stay available whichever window has the focus. The connection state indicator becomes a read-only LINK menu there instead of the status bar button. Other platforms are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * List direct commits on main in the release notes GitHub's generated release notes only cover merged pull requests, so commits pushed straight to main were missing. The release job now builds the notes itself: "What's Changed" holds "Commits on main" (first-parent, without bot and squash-merge commits) and GitHub's PR list as "Merged PRs". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Build with Gradle in two modules, and free core of JavaFX Etappen 1 and 2 of the Compose migration (43 commits). The Maven build, the single source tree and the JPMS module-info went together. core now holds the domain and app-desktop the user interface, both built by Gradle, packaged through jpackage from Gradle, with SpotBugs and PMD wired in. JavaFX moves to the classpath, which is why the launcher is Main and not the Application subclass. The PR check, the nightly artifacts, the release and the AUR packages all build from Gradle; the macOS DMG points at its output. Verified on Linux, macOS and Windows. core then loses JavaFX entirely. It observes through kst4contest.observe -- ObservableValue, ObservableRoster, and UiDispatcher as the one boundary a worker thread crosses to touch the interface. The controller collections become rosters and the visible station list a pure derivation rather than a FilteredList/SortedList chain, which is also what fixed two focus defects only a load test had exposed: the keyboard focus stays where the operator put it, and the send field keeps it after a row click. The rule that outlives this commit: ObservableRoster is the store and the list a view is bound to is a mirror of it, never the other way round. * Draw the whole interface in Compose Etappen 3 to 6a of the migration (129 commits). Every window the operator sees is Compose; the JavaFX ones still exist beside them so the two could be compared against a live session, which is the only way the differences came to light. The toolchain first, then the settings window with its eleven tabs and 72 real preferences; then the multi-column table as a component, and with it the rules it needs -- stable row identity, a selection that survives a refresh, column order the operator can drag, and a repaint when the rows change rather than when the list instance does. Then the update and monitor windows, and the main window: 22 station columns, the filter bar, the selected-station panel, the message tabs, the priority bar, the sked controls, the status indicators and the timeline, assembled behind a splitter because Compose has none. The map stops being a WebView. A Compose canvas projects WebMercator tiles itself, with the clustering in core and an asynchronous fetcher in place of the local tile proxy; derive() becomes a pure Kotlin reimplementation instead of a reflection call into com.sun.javafx. Most of the volume here is parity the operator would notice rather than new behaviour: desktop density instead of Material's phone minimums, colours taken from the JavaFX stylesheets instead of Material's palette, row dividers, band columns, grid-square labels and their colours, the home marker and antenna beam, pinch-to-zoom under Wayland, and layouts that survive a window narrower than the chart they stack. Two lessons are worth more than the diff. A control bound to a value Compose cannot observe writes through and never redraws -- that one shipped repeatedly with a green build, because no test drew anything. And a layout that clips instead of wrapping is worse than one that is merely too narrow: half a word is the worst available outcome. * Remove JavaFX The second half of Etappe 6 (61 commits). grep -rl "javafx\." over both main source trees is empty, nothing imports javafx, neither classpath resolves it, and org.openjfx is out of the build and the version catalog. The finding that shaped the work: the JavaFX main window was built on every start and never shown -- primaryStage's setScene and show were both commented out. Most of those 11,655 lines were dead weight rather than a port. But not all of them, and that is the trap this commit is really about: dead-looking methods still fed live Compose sinks. They were cut at their seams instead of deleted, and a sweep script that follows calls was written to find them, because reading the code does not reveal them. In order: the colour derivation frozen as checked-in test data, so the pin survives JavaFX being removed instead of silently comparing against itself; the live feeds lifted out of the never-shown window and given names and tests; the dead scaffolding deleted in slices; then the lifecycle. UiDispatcher now delivers to the AWT event dispatch thread, the ten Alerts are modal Compose dialogs, HostServices gives way to java.awt.Desktop with the mailto/http split JavaFX did not need, and extends Application, start(Stage), stop and launch are gone -- main builds the runtime and a shutdown hook replaces stop(). An independent review found two deadlocks in that move, both the same failure class, both invisible to the build: a blocking wait on the event thread for work that can only advance on the event thread. The profile picker waited on a latch and froze the client for good; ComposeWindowHost.close waited on Thread.join and returned with the window still marked open, which made a profile switch raise the dead runtime's window and leave the rebuilt profile without its Connect button. A third came out of fixing them: a ComposeDialog built off the event thread cannot create its GL context and never paints. Three defects only a GUI run showed, never the build: an NPE on a deleted field, a Compose menu still hanging on deleted MenuItems, and a category bookkeeping field that looked dead but is read by the outgoing-message category resolution -- deleting it would have sent messages in the wrong category. The binding docs and the manual no longer describe a JavaFX client. * Draw the menu bar in Compose, and give the drawing layer a net What the removal left open (4 commits). Compose's MenuBar is a javax.swing.JMenuBar set on the window, so Swing draws it and no theme reaches it; with no look-and-feel configured that meant the default Metal menu above a themed window. The bar is drawn in the window now, except on macOS, where the system bar is where that platform expects it. Two renderers read one description -- mainMenuModel is a plain function of the state, which also gives the menus their first tests. Closing the main window quits the application again, and the window writes its size back to the profile; both had quietly stopped working when the last JavaFX stage went. Then Etappe 7. Four faults shipped in the settings-window branch alongside a green suite of 382 tests, because not one of those tests drew anything: a control that never redrew, a tab strip that clipped mid-word, a form taller than its window with no way down, and colours that came from Material rather than the stylesheet. One regression test per class, and the spec's acceptance criterion is met rather than assumed -- each fault was put back deliberately and the matching test watched to fail. The CI had never run the suite at all; it does now, headless. What that took was not Xvfb: skiko's native library links against libGL and only has to be loadable, since the drawing tests render in software. Without the package the whole Compose half of the suite dies with a message that reads like a missing display. Found by running the job under act rather than on GitHub. The six tests that open a real window skip headless by their own guard. The summary step counts from the result XML and fails on failures there, because this project's rule is never to infer a green suite from an exit code. * Make the colours adjustable per operator profile Six colour roles per design, per profile: surface, window surface, field interior, text, accent and separator line. A change applies at once in every open window and survives a restart once the settings are saved, like any other preference. Three sources, later wins role by role: the shipped stylesheet from the classpath, then the profile's own stylesheet file if there is one, then the overrides stored in the profile's preferences. resolvePalette is a pure function and reports where every role's colour came from, which the tab shows per field -- with two sources able to decide one colour, that is the only thing keeping "why is this colour what it is" answerable, and the spec calls it mandatory rather than decorative. Four things this had to get right, each learned the hard way and each pinned: A role is a selector and a property, not a property alone. Three of the six are stated outside .root -- text on .label, the separator on .separator *.line -- and -fx-background-color alone appears a dozen times in the evening sheet. Measured: the shipped daylight sheet states no colour at all, the evening sheet states five and implies the sixth. Kst4ContestTheme reads the palette from the store's state and not from remember. That read is what makes a change repaint every open window; remember(darkMode) held the palette until somebody toggled day/evening, so a change reached nothing. A derived colour follows its source's value, never its provenance. The root profile's own stylesheet is the one copyResourceIfRequired writes at every startup -- the shipped sheet itself -- so layer 2 declares the accent on every existing installation with nobody having chosen anything. Keying textAccent on "does this come from a file" repainted the evening accent from green to blue on upgrade and made "reset to shipped" disagree with "discard my changes". The contrast guard measures where colours are actually drawn, read off Theme.kt's Material mapping rather than off the role names: background and surface are both the window surface, and primary is textAccent, not accent. It reports a pair only when it is both under WCAG AA and worse than the shipped sheet -- the shipped sheets have three pairs under 4.5 themselves, so an absolute floor would warn on an untouched client and teach the operator to ignore warnings. The way back out of an unreadable palette is deliberately overbuilt, because it is the one failure that locks itself in. "Reset to the shipped colours" takes the shipped palette as a required parameter and reads no composition local, so there is no path by which it could be drawn in the colours it exists to undo; it looks out of place under a customised palette, and that is what makes it findable. Ctrl+Z, Ctrl+D and Ctrl+R reach the three ways back even with the caret in a colour field. A mistyped colour is refused and the field snaps back. The profile's stylesheet is the hand-editing route the copy under ~/.praktiKST has been promising since it was first written and never read. It is read now. A button writes the shipped template as a starting point and never replaces a file that is already there. An unreadable, truncated or non-CSS file does not prevent startup -- the role falls back to the shipped design. A sheet stating -fx-base and no -fx-background states the derived window surface too, the way JavaFX does, or the most natural hand edit would leave every window the shipped light grey. 101 new tests. All of it runs headless. * Document the adjustable colours, and record the design and the plan Both manuals get the Colours tab in full: the six roles, that a change applies at once but survives a restart only after Save settings, the three ways back with their keyboard shortcuts, what each provenance label means, and the readability notice that warns without refusing. Two things an operator would otherwise have to discover. The reset button is always drawn in the shipped colours and works when nothing else can be read -- the risk section of the design says plainly that a keyboard path only helps whoever knows it, so the manual is where this has to be written down. And the root profile already has both stylesheet files, because KST4Contest has been writing them at startup for years, so most of its roles report "from file" rather than "shipped" with identical values. PROJECT_CONTEXT.md records the decisions that outlive this stage: the three sources and their precedence, that a role is a selector and a property, that the theme must read the store's state rather than remember, where the contrast pairs come from, why the root profile's file layer always exists, and why the lifeline refuses the active palette. Also corrects its claim that CSS stays global -- a profile now owns its stylesheets. The design document and the implementation plan are kept as they were written, including the plan's own corrections where measuring the code contradicted it. * Speak the operator's language The interface is German or English, chosen per operator profile on the GUI tab, in force at once in every open window, and remembered across restarts. 376 texts in both languages. The texts are ordinary .properties files that nobody has to compile: a contributor copies the English one, translates the values, and opens a pull request. A third module -- build tooling that never ships -- turns them into Kotlin before anything compiles, which is what makes a mistyped key and a wrong argument count compile errors rather than things an operator discovers. It lives in the main build rather than buildSrc because buildSrc's tests do not run on `./gradlew build`, measured, and a generator whose tests never run is the exact failure it exists to prevent. Incompleteness is allowed and incorrectness is not. A missing key warns and falls back to English, so a partial contributed language can be submitted at all; an orphan key, a placeholder the translation drops, a duplicate key or an unreadable file fail the build with the generator's own message naming the file. The argument count always comes from the English base. German is held complete by a test because it ships; a contributed language is not. What is deliberately not translated is the harder half. Protocol frames and chat commands would break the connection or go unread; the beacon texts, auto answers, snippets and shortcuts go to other radio amateurs and sit in every operator's stored profile; the 273 println calls in core are diagnostics, and a German stack trace is worse for whoever reads the bug report; and QRA, QRG, QTF, LOS, Fresnel and wkd read the same in either language. Three tests guard the boundary by measuring behaviour rather than text: the protocol frames built under three locales, every preference default compared by reflection, and no translation value being a protocol command. The reflective one is the only one that covers what nobody thought of. One insight turned up three times. Anything built outside a composition freezes the language it was built in: the window title, the settings tab strip and every column header are all constructed once at startup -- the columns from Java -- so each now holds a function read when it is drawn. That also fixed something older and unrelated to language: the main window's title was a fixed "KST4Contest (Compose)" for the whole session, where the JavaFX window had carried the live connection line. It carries it again. A column's id is never translated. It is what the remembered widths and order are keyed on. * Document the two languages, and how to contribute a third Both manuals get the language picker in full: where it sits, that it applies per profile and takes effect at once in every open window, and -- at more length -- what is deliberately left alone and why. An operator who sees an English beacon text in a German client should be able to read that it is meant that way. The contribution route is written down in both, because plain text files are only useful if somebody knows they are there: copy, translate, submit; a partial file is welcome; the build reports mistakes by file name and writes a worksheet of what is still missing. PROJECT_CONTEXT records the decisions that outlive this stage -- the four kinds of text and the rule that the addressee decides, that core produces no display text, that incompleteness is allowed and incorrectness is not, that anything built outside a composition needs its text read inside one, and that a column id is never translated. CLAUDE.md said two modules; there are three, and the third never ships. It also states the German orthography now, which this session got wrong across a spec and two plans: ss after a short vowel, so muss and dass. * Remove the implementation plans now that every stage is executed Thirteen plans, all of them step-by-step instructions for work that is committed. A plan left behind reads to the next person like an open intention, and these describe a build that no longer exists -- the first still explains how to introduce Gradle. The specifications stay. They say why the architecture is what it is, which the code cannot, and three of them are still argued from. The live-findings note stays too: CLAUDE.md sends people to it, and its hardest lesson -- that a blocking wait on the AWT event thread deadlocks the interface while the build stays green -- is written down nowhere else. Its sweep script stays as well. The note argues explicitly that the script belongs beside the finding so the next reader can measure rather than believe, and removing it would contradict the reasoning it illustrates. Two references in the note and one in the JavaFX-removal spec pointed at plans and now say where the reasoning went instead. * Point the JavaFX-removal spec at where its plan's reasoning went * Remove the stray release-metadata patch from the working tree A 416-line patch file that was applied long ago and has sat in the repository root since. It predates this branch and stays in the shared history, where rewriting it would mean rewriting commits that are already on main and on origin. * Check the translation files in CI and say what they hold classes already runs the generator, so an orphan key, a dropped placeholder or a duplicate fails the compile job with the generator's own message naming the file -- verified by breaking strings_de.properties on purpose. A step summary counts each language against the base, so the author of a translation PR sees what they covered without reading the build log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Refuse a translation key that would not form a Kotlin name The generator escaped every translation value but emitted the key verbatim as the member identifier, and identifierFor strips only . _ - -- so a key carrying a space, a brace, a quote or a newline from a \uXXXX escape broke out of val <name>: String get() = lookup(...) into an init block or property initializer that runs when Strings is instantiated. Translation files are the contribution surface that arrives by pull request, so this was a path from a merged .properties change to code in every client. The generated identifier is now held to letters-then-letters-and-digits before any source is written, alongside the existing orphan and collision refusals. Proven by replaying a file-writing payload against the built generator: it now throws and writes nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Port the rebased diagnostics and session logging onto the modules origin/main landed replayable session logging (MessageHistoryRecorder), file logging (ApplicationFileLogging) and a user-list refresh split on the old flat layout. The rebase carried the new files, but three things needed the new architecture: - ChatController.fireUserListUpdate() used javafx Platform; core is toolkit-free now, so it dispatches through uiDispatcher like every other fire method. - Two new tests were left in the old src/test/java; moved into core. - ScoreServiceRefreshTest mocked javafx Platform statically; it now injects the DirectUiDispatcher the no-arg constructor installs. The Leaflet map performance work was dropped with the HTML map it optimised. classes testClasses and test are green: 1069 tests, 0 failures, 3 skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Give the debug-to-file recording a home in the Compose settings origin/main added a checkbox to the old JavaFX settings that recorded the whole ON4KST session to file; the Compose redraw dropped the old settings UI, so the toggle had no control left even though the preference and its wiring survived the rebase. It returns to the message-handling tab: the state writes the preference and asks the application, through a new SettingsHost callback, to open or close the error-log handler and the history recorder in the order the old checkbox kept. The explanatory line and its German translation say that passwords are redacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Fix Codex review findings on PR 89: station row key, map selection, sort after filter - Station row key now includes the chat category, so the same callsign in two categories no longer collides. - Map marker click and Reset view go through the central station selection. - Sorting now operates on the filtered rows, so filters stay effective. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Keep the map drawing test off the network and the user's tile cache The test assumed no tile ever arrives, but it used the default TileFetcher, which reads the real disk cache and the OSM tile server. On CI a tile now and then landed before the frame was rendered and covered the background the 'unreachable tile source' test asserts on. An empty temporary cache and a source that always fails make the assumption hold by construction. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
 Marc Froehlich
|
3e8457eede | Optimize station map refresh performance | ||
|
Marc Froehlich
|
df70cb1943 |
Update diagnostics and analytics context
Silence the UTC time formatting console diagnostic and document the current production analytics status. |
||
|
Marc Froehlich
|
323c249bf7 |
Add replayable ON4KST session logging
Record redacted RX/TX frames with session rotation and runtime debug controls. Add targeted file diagnostics, tests, documentation, and a silent priority-score refresh path. |
||
|
Marc Froehlich
|
a3f3bf8872 | Changes at the stats analytics | ||
|
Marc Froehlich
|
393c9c49ee | Changed link monitoring as described by on4kst, Alain | ||
|
Marc Froehlich
|
923d76beb0 | refactoring project website landing page | ||
|
Marc Froehlich
|
821535a24f | Documentation on user counter and analytics to the kst4contest page | ||
|
Marc Froehlich
|
914a06cb7f | Corrections on user counter and analytics to the kst4contest page | ||
|
Marc Froehlich
|
b23884bde1 | Added user counter and analytics to the kst4contest page | ||
|
Rsclub2_2
|
634b88238d
|
WT-Logsync when KST4C is not actively receiving WT Packets,
so that we can later mark QSOs as marked, even though we never received the packet. |
||
|
Marc Froehlich
|
7ee50267ec | Document v1.43 and fix release metadata | ||
|
Marc Froehlich
|
53555cbe69 | Add optional station map clustering toggle (solves #79) and added documentation | ||
|
Marc Froehlich
|
9eb0550106 | Persist table layouts just after changing the real used sizes and show truncated cell tooltips in the whole applications tables | ||
|
Marc Froehlich
|
51aa04bfb5 | Fix DX Cluster spot formatting - emit fixed 75-character DXSpider-compatible lines - align callsign, comment, and UTC fields - support frequencies up to 24 GHz - reject overlong callsigns instead of truncating them - add protocol tests and update documentation Fixes #86 | ||
|
Marc Froehlich
|
6b0d699a98 | Fix compact QRG parsing and initial worked-state restore - parse digit-only full frequencies across supported bands - restore persisted Worked state before publishing initial user lists - add regression tests and update documentation Fixes #85 | ||
|
Marc Froehlich
|
6b29ffe3ba | refactored the ugly switch case statement in logged-band-recognition | ||
|
Marc Froehlich
|
08b109106e | manual: corrected behaviour description of simplelogfile, Airscout, MYQTF, corrected some typos | ||
|
Marc Froehlich
|
21b2d9970a | manual: decribed SimpleLogFile-parser | ||
|
Marc Froehlich
|
d475c6b2c4 | manual: wording corrected for the settings at different places | ||
|
Marc Froehlich
|
211be6081d | manual: described dual chat | ||
|
Marc Froehlich
|
7ff7248e7d | Fixed KST4Contest caused disconnect on getting no activities of ON4KST chatservers if no new lines arriving | ||
|
Marc Froehlich
|
4601199587 | chore: add Codex project context and agent guidance |