mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-10-18 21:34:03 +02:00
Rsclub2_2andClaude Opus 5.5
81b16ad4c5
* Keep tests out of the user profile The no-argument ChatPreferences constructor seeds preferences.xml in ~/.praktiKST when it is missing, so 21 older test files could create a profile file for whoever ran the build. They now use ChatPreferences(Path) with a @TempDir. None of them reads the file: their assertions are on the field initialisers, which both constructors share, so no assertion changes meaning. ChatPreferencesStationMapVisibilityTest passes its file to the constructor instead of redirecting it with the setter afterwards. The two opt-in ON4KST practice tests keep the no-argument constructor: they deliberately read the operator's real profile for live credentials. As a net, the test tasks run with user.home pointed at build/test-user-home, emptied before each run, and fail if a preferences.xml appears there. This also keeps the sound files, the map tile cache and the Skiko native library that tests unpacked into the real home directory out of it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Make DXClusterThreadPooledServer.serverSocket volatile run() assigns the server socket on the server thread, and stop() closes it from another thread. closeServerSocket() is synchronized, but the write in run() is not, so nothing guaranteed that stop() saw the socket run() had opened; it could find null and leave the socket listening. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Drop the ineffective SO_REUSEADDR from the Win-Test sked socket WinTestSkedSender.sendUdp() set reuse address on a socket the constructor had already bound, where it has no effect, so it was never in effect in any shipped version. The socket binds an ephemeral port and only sends, which gains nothing from it, and enabling it for real would change UDP multi-bind semantics on Windows. Removing the call keeps the behaviour exactly as shipped and stops the code from claiming an option it does not have. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Check the test user.home in a finalizer task The stray-preferences check ran as a doLast of the test task, which Gradle skips once a test fails, so a failing run could hide the file. It is now a separate task, checkTestUserHome, that every test task is finalized by; finalizers run when the test task fails too. It captures only a File, so it stays configuration-cache safe. Each test task now gets its own scratch home, build/test-user-home/<task name>, so a second test task cannot wipe another's. Emptying it checks the result of deleteRecursively(), which reports failure instead of throwing, and stops the task, so a leftover file is never blamed on the current run. The check stays limited to preferences.xml. Other files land in the scratch .praktiKST by design, such as the sound files PlayAudioUtils seeds from the bundled resources; absorbing those is the redirection's job, and a wider check would need an exclusion list that grows with every seeded file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Keep generateStrings configuration-cache safe The argument provider of generateStrings referenced the script-level generatedI18nDirectory, which captures the build script object, so storing the configuration cache failed for every build that included app-desktop. The task now works on a local copy of the provider. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Declare the test user.home as a test task output Test tasks are cacheable, and a cache hit skips doFirst, so the scratch home was neither emptied nor rewritten and checkTestUserHome judged whatever an earlier run had left there: a false alarm after a violating run, or a hidden violation when a passing result for violating inputs came from the cache. The scratch home is now a declared output, restored and replaced together with the cached result, so the check always sees the files belonging to the inputs. The doFirst wipe stays for real executions. Skiko unpacked its native library, about 30 MB, into the scratch home, which would now land in every app-desktop cache entry. skiko.data.path points it at build/skiko-data instead, outside the output and kept between runs. user.home and skiko.data.path are passed through an argument provider: as system properties they would be task inputs, and their absolute paths would make the cache key differ between checkouts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
KST4Contest
KST4Contest is a Java-based client for the ON4KST chat, developed for coordinated VHF, UHF and microwave contest operation.
The application is developed by Marc Fröhlich (DO5AMF) and since 2026 Philipp Wagner (DN9APW).
Start here
- Project website
- Download Stable, Beta and Nightly builds
- Online manual
- GitHub wiki
- Issues and bug reports
- Development roadmap
What KST4Contest does
KST4Contest combines the ON4KST chat with information that is useful when coordinating contacts during a contest.
Among other things, it can:
- display and filter stations from the supported ON4KST chat categories;
- derive band and frequency information from chat messages and station names;
- maintain Worked and NOT QRV information for the available bands;
- calculate station priorities from distance, activity and other available information;
- manage internal skeds and received Win-Test skeds;
- use AirScout information when evaluating possible aircraft-scatter contacts;
- display stations, paths and additional propagation information on maps;
- exchange information with supported logging programs, Win-Test, PSTRotator and a local DX Cluster interface;
- provide configurable automatic replies for recurring chat requests.
Calculated scores, aircraft-scatter information and path assessments are operating aids. They depend on the available data and should not be treated as guarantees that a contact is possible.
Installation
Ready-to-use packages are available for Windows, Linux and macOS. These packages include the required Java runtime, so a separate Java installation is normally not necessary.
Use the central download page to select the appropriate build:
- Stable is intended for normal contest operation.
- Beta contains changes that are being prepared for a stable release.
- Nightly contains the latest automated development build and is mainly intended for testing.
Documentation
The documentation is available in German and English:
The Markdown sources used for the wiki and the generated PDF manuals are stored in github_docs.
Changes to operating behaviour should be documented together with their purpose and limitations. This is especially important for functions whose result depends on external data, heuristics or information derived from chat messages.
Building from source
Building KST4Contest requires JDK 21. The Gradle Wrapper included in the repository should be used, so a separate Gradle installation is not required.
Linux and macOS:
./gradlew clean build
Windows:
.\gradlew.bat clean build
Repository structure
core/– domain, controller and network code, free of user-interface technologyapp-desktop/– the Compose Multiplatform user interface and the packaging tasksgithub_docs/– German and English manual sourceswebsite/– project website sourcespackaging/– platform-specific packaging files
CI status
Documentation
Builds
License
KST4Contest is distributed under the GNU General Public License v3.0.
Supporters/Sponsor
This Project is possible due to donations of the community.
You can sponsor KST4Contest here: Support on Ko-Fi. If you add an Display Name there you will be mentioned here.
The following people are sponsoring KST4Contest:
- Marco (DJ5KW)