5f63c5032c
Adds the four onboarding pieces that were missing:
- flywithlua_present Tauri command + wizard step that checks the plugin and
links the FlyWithLua NG+ download when it's absent.
- Wizard step explaining how to enable X-Plane's Web/REST API (Settings>Network).
- FlyWithLua-Sync status row in the live diagnostics, from /api/health.lua
('N Skripte aktiv' / 'FlyWithLua fehlt' / 'kein X-Plane').
- 4-step guided wizard (X-Plane folder → FlyWithLua → Web-API → install+start)
that auto-opens on first launch and is reachable via the header Einrichten
button; the final step hands off to the normal server start (auto-installs Lua).
Verified the wizard DOM flow + the dLua status against a live bridge.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
X-Plane Cockpit — Desktop App
A small launcher (Tauri) that runs the G1000 web cockpit's server on your PC and shows the LAN address tablets/laptops open. The Node "bridge" server is bundled as a Bun-compiled sidecar, so nothing else needs to be installed.
Using it (for a tester)
- Install & open X-Plane Cockpit.
- macOS: open the
.dmg, drag the app to Applications. It's ad-hoc signed (no Apple Developer ID), so on first launch use right-click → Open and confirm, or runxattr -dr com.apple.quarantine "/Applications/X-Plane Cockpit.app". - Linux: make the
.AppImageexecutable (chmod +x) and run it, or install the.deb.
- macOS: open the
- Point it at your X-Plane 12 folder (it auto-detects common locations). No X-Plane handy? Tick Demo-Modus to try the cockpit with synthetic data.
- Make sure X-Plane's Web API is on: X-Plane → Settings → Network → Enable web server / API (X-Plane 12.1.1+).
- Click Server starten. Open the shown URL (e.g.
http://192.168.1.27:8080) on any tablet/laptop on the same Wi-Fi. The PFD/MFD/Map/FMS buttons open pages directly.
Updates: Nach Updates suchen in the footer pulls the latest release from Gitea.
LAN only by design. Don't expose the port to the public internet.
Building (for the developer)
From the repo root:
# 1. prep: build the web cockpit + compile the Bun sidecars (mac + linux)
bash scripts/prep-desktop.sh
# 2a. macOS app (native, ad-hoc signed) + updater artifacts
APPLE_SIGNING_IDENTITY="-" \
TAURI_SIGNING_PRIVATE_KEY="$(cat desktop/.tauri-signing.key)" \
TAURI_SIGNING_PRIVATE_KEY_PASSWORD="$(cat desktop/.tauri-signing.pw)" \
npx --prefix desktop tauri build --target aarch64-apple-darwin
# 2b. Linux AppImage + .deb (x86_64) via Docker
bash scripts/build-linux.sh
# 3. publish to Gitea + refresh the updater's latest.json
GITEA_URL=https://git.kgva.ch GITEA_REPO=karim/xplane-cockpit \
GITEA_TOKEN=$(cat /tmp/gitea_token) \
node scripts/release-gitea.mjs
Testing the auto-updater (two versions)
The updater only fires when latest.json advertises a version newer than the
installed one. So to test it end-to-end:
# 1. publish the baseline the tester installs
# (version 0.1.0 in tauri.conf.json) → release-gitea.mjs uploads assets + latest.json
# 2. install that 0.1.0 build on the test machine
# 3. bump the version, rebuild, re-release:
# edit desktop/src-tauri/tauri.conf.json "version": "0.1.1"
bash scripts/prep-desktop.sh
APPLE_SIGNING_IDENTITY="-" TAURI_SIGNING_PRIVATE_KEY="$(cat desktop/.tauri-signing.key)" \
TAURI_SIGNING_PRIVATE_KEY_PASSWORD="$(cat desktop/.tauri-signing.pw)" \
npx --prefix desktop tauri build --target aarch64-apple-darwin
bash scripts/build-linux.sh
GITEA_TOKEN=$(cat /tmp/gitea_token) node scripts/release-gitea.mjs
# 4. in the installed 0.1.0 app: launch → silent check shows the update banner,
# or click "Nach Updates suchen" → Installieren → app relaunches as 0.1.1.
The updater signing keypair lives in desktop/.tauri-signing.key(.pub/.pw) —
keep the private key + password safe; they never go into the bundle or Gitea.
The matching public key is embedded in tauri.conf.json (plugins.updater.pubkey).