Rsclub2_2 cc8c90204e 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.
2026-10-05 22:33:28 +02:00
2026-10-05 22:33:28 +02:00
2026-10-05 22:33:28 +02:00
2023-11-10 08:33:17 +01:00
2026-10-05 22:33:28 +02:00
2026-10-05 22:33:28 +02:00
2024-01-16 22:51:30 +01:00
2023-11-09 22:53:59 +01:00
2023-11-14 00:50:10 +01:00
2023-11-10 08:33:17 +01:00

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

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.

Open the download page

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 technology
  • app-desktop/ – the JavaFX user interface and the packaging tasks
  • github_docs/ – German and English manual sources
  • website/ – project website sources
  • packaging/ – platform-specific packaging files

CI status

Documentation

Publish wiki

Docs PDF

Builds

Nightly Runtime Artifacts

License

KST4Contest is distributed under the GNU General Public License v3.0.

S
Description
No description provided
Readme GPL-3.0
1 GiB
0 Stars 1 Watchers 0 Forks
Languages
Java 54%
Kotlin 36.3%
JavaScript 5%
Nunjucks 1.8%
CSS 0.9%
Other 2%