https://github.com/software-challenge/gui
Software-Challenge Grafischer Spieleserver
https://github.com/software-challenge/gui
gui kotlin software-challenge tornadofx
Last synced: about 1 month ago
JSON representation
Software-Challenge Grafischer Spieleserver
- Host: GitHub
- URL: https://github.com/software-challenge/gui
- Owner: software-challenge
- Created: 2020-04-10T13:20:56.000Z (about 6 years ago)
- Default Branch: main
- Last Pushed: 2026-04-02T10:11:57.000Z (about 1 month ago)
- Last Synced: 2026-04-03T00:49:47.908Z (about 1 month ago)
- Topics: gui, kotlin, software-challenge, tornadofx
- Language: Kotlin
- Homepage: https://software-challenge.de
- Size: 29.2 MB
- Stars: 11
- Watchers: 2
- Forks: 3
- Open Issues: 17
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
Awesome Lists containing this project
README
## 
Grafischer Spieleserver der Software-Challenge Germany 
Dies ist die Grafische Oberfläche für die Software-Challenge Germany,
seit Saison 2020/21 in Kotlin TornadoFX aufbauend auf JavaFX.
Nutzerdokumentation: https://docs.software-challenge.de/server.html
> Hinweis: Wenn als erster Parameter des Programms eine Zahl mitgegeben wird,
wird der Server auf diesem Port Verbindungen von Spielern erwarten.
## Für Entwickler
### Erste Schritte
- zuerst das Projekt lokal mit Submodulen klonen:
```sh
git clone git@github.com:software-challenge/gui.git --recurse-submodules --shallow-submodules
```
- mindestens Java 11 wird benötigt
(ggf. `org.gradle.java.home=/path/to/jdk` in `gradle.properties` setzen)
- `./gradlew run` ausführen
### Kollaboration
Unsere Commit-Messages folgen dem Muster `type(scope): summary`
(siehe [Karma Runner Konvention](http://karma-runner.github.io/6.2/dev/git-commit-msg.html)),
wobei die gängigen Scopes in [.dev/scopes.txt](.dev/scopes.txt) definiert werden.
Nach dem Klonen mit git sollte dazu der hook aktiviert werden:
git config core.hooksPath .dev/githooks
Um bei den Branches die Übersicht zu behalten,
sollten diese ebenfalls nach der Konvention benannt werden,
z. B. könnte ein Branch mit einem Release-Fix für Gradle `chore/gradle/release-fix` heißen
und ein Branch, der ein neues Login-Feature zur GUI hinzufügt, `feat/gui-login`.
Wenn die einzelnen Commits eines Pull Requests eigenständig funktionieren,
sollte ein rebase merge durchgeführt werden,
ansonsten (gerade bei experimentier-Branches) ein squash merge,
wobei der Titel des Pull Requests der Commit-Message entsprechen sollte.
Detaillierte Informationen zu unserem Kollaborations-Stil
findet ihr in der [Kull Konvention](https://kull.jfischer.org).
### Java-Versionen und Abhängigkeiten
Aktuell können die Backend-docs nur mit JDK 8 gebaut werden,
dieses Projekt braucht jedoch für [tornadofx](https://github.com/edvin/tornadofx2)
mindestens Java 11.
Daher müssen die Releases separat gebaut werden.
Tornadofx wird leider seit einigen Jahren nicht mehr entwickelt.
Wir schauen gerade wie es da weitergeht.
Eventuell ein eigener Fork.