feat(windows): echtes Fenster statt Browser-Tab (WebView2 statt Electron)

Auf die Frage des Commanders: "Warum nutzen wir fuer Windows weiterhin
einen Browser? Warum nutzen wir kein Electron oder sowas und machen daraus
einen echten Client."

Die erste Haelfte trifft zu und ist umgesetzt. Die zweite ist abgelehnt --
gemessen, nicht geschaetzt:

    pywebview + WebView2     8,0 MB in der Bau-Umgebung, 2,7 MB in der EXE
    Electron               150-210 MB, dazu eine zweite Laufzeitumgebung

Windows 11 bringt die WebView2-Laufzeit mit (hier 151.0.4129.107).
Nachgemessen statt angenommen, was sie rendert:

    navigator.userAgent  ...Chrome/151.0.0.0 Safari/537.36 Edg/151.0.0.0
    fetch ja   EventSource ja   CSS Grid ja   Pfeilfunktionen ja

Dasselbe Chromium, das auch in Electron steckt -- nur ohne es ein zweites
Mal mitzuschleppen. RippySetup.exe waechst von 29,0 auf 31,7 MB.

Drei Dinge gehoeren dazu, nicht als Beiwerk:

* Kein stiller Rueckfall auf MSHTML. Der alte IE-Renderer stellt die
  React-Oberflaeche nicht dar. Fehlt WebView2, oeffnet Rippy den Browser
  und SAGT warum -- ein leeres Fenster waere schlimmer als ein Tab.
* Fenster und Tray sind getrennte Prozesse. pystray belegt unter Windows
  den Haupt-Thread, das Fenster braucht ihn genauso.
* Die eigene Konsole wird versteckt, eine geerbte nie. GetConsoleProcessList
  unterscheidet beides: genau ein Prozess an der Konsole heisst, sie
  gehoert uns. Ohne diese Unterscheidung haette "Rippy.exe --status" im
  Terminal das Terminal des Nutzers verschwinden lassen.

fix(windows): Oberflaeche neben das Programm legen statt aus %TEMP% bedienen

Beim Nachsehen im laufenden Betrieb gefunden: Ein Dienst lief eine Stunde,
/api/health gab HTTP 200, / gab 404. Im Fenster stand {"detail":"Not Found"}.

Der Server war in Ordnung. Sein Entpack-Verzeichnis war es nicht:

    _MEI000074b02   31 Eintraege,  5 Ordner   -- kein ui, kein api
    _MEI000082e82   44 Eintraege, 16 Ordner   -- vollstaendig

Eine PyInstaller-Onefile-EXE liest bei JEDER Anfrage aus %TEMP%\_MEIxxxxx.
Ein Temp-Verzeichnis ist kein Ort fuer etwas, das eine Woche liegen bleibt.
Und der Ausfall ist der schlimmstmoegliche: Die API antwortet weiter, der
Dienst gilt als gesund, nur die Oberflaeche ist weg.

Genau davor warnte ROADMAP.md beim Bau-Verfahren ("one-dir statt one-file").
Die Abweichung bleibt, die Luecke wird geschlossen: Der Installer legt die
Oberflaeche neben das Programm, daemon._ui_pfad() nimmt diese Kopie zuerst.
Zeigt sich derselbe Ausfall an den API-Modulen, ist one-dir die Antwort.

Ampel: 562 gruen, ruff sauber. Fenster mit der echten Oberflaeche im
Bildschirmfoto nachgewiesen, nicht nur der Titel geprueft.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
2026-08-28 12:14:15 +02:00
co-authored by Claude Opus 5
parent 069fc46f44
commit c01ef1081c
12 changed files with 971 additions and 34 deletions
+53
View File
@@ -1267,6 +1267,59 @@ Eingabemaske — nur der Knopf „Verbinden" wird zu „Zeile kopieren".
`apparmor:unconfined`, `propagation: rshared` und die Mount-Wache fallen in
V2-5 ersatzlos weg.
### Entscheid 4 — Echtes Fenster statt Browser-Tab, aber ohne Electron
Nachgefragt vom Commander am 28.08.2026:
> „Warum nutzen wir für Windows weiterhin einen Browser? Warum nutzen wir kein
> Electron oder sowas und machen daraus einen echten Client?"
Die erste Hälfte trifft zu und wird umgesetzt: Ein Browser-Tab ist kein Client.
Er hat eine Adresszeile, die niemand braucht, liegt zwischen fremden Tabs, hat
kein eigenes Symbol in der Taskleiste, und wer den Browser schließt, glaubt, er
habe Rippy beendet.
Die zweite Hälfte wird **abgelehnt**, und zwar gemessen statt geschätzt:
| Weg | Zusatz zum Paket | Was mitkommt |
|-----|------------------|--------------|
| **pywebview + WebView2** | **8,0 MB** | nur die Anbindung; der Renderer liegt schon auf dem System |
| Electron | ~150210 MB | ein komplettes zweites Chromium **und** eine zweite Laufzeitumgebung neben Python |
Windows 11 liefert die WebView2-Laufzeit mit. Auf dem Rechner des Commanders am
28.08.2026 nachgesehen: **151.0.4129.107**. Und nachgemessen, was sie wirklich
rendert — nicht angenommen:
```
navigator.userAgent …Chrome/151.0.0.0 Safari/537.36 Edg/151.0.0.0
fetch ja EventSource ja CSS Grid ja Pfeilfunktionen ja
```
Das ist dasselbe Chromium, das auch in Electron steckt. Rippy bekommt also
denselben Renderer, nur ohne ihn ein zweites Mal mitzuschleppen. Damit bleibt
auch § 4.1 unverändert gültig — dort stand WebView2 von Anfang an.
**Drei Dinge gehören zum Entscheid, nicht als Beiwerk:**
1. **Kein stiller Rückfall auf MSHTML.** `pywebview` kann unter Windows auch den
alten IE-Renderer nehmen; der stellt die React-Oberfläche nicht dar. Fehlt
die WebView2-Laufzeit, öffnet Rippy **den Browser** und sagt warum — ein
leeres Fenster wäre schlimmer als ein Tab.
2. **Fenster und Tray sind getrennte Prozesse.** `pystray` belegt unter Windows
den Haupt-Thread, das WebView2-Fenster braucht ihn genauso; zwei
Nachrichtenschleifen passen nicht in einen Thread. `--dienst` hält Server und
Tray, `--oeffnen` ist der Client davor. Beide heißen im Taskmanager
`Rippy.exe`, und das Fenster lässt sich schließen, ohne den Dienst
mitzureißen.
3. **Die eigene Konsole wird versteckt, eine geerbte nie.** `Rippy.exe` ist ein
Konsolenprogramm, weil der Installer seine Meldungen zeigen muss. Beim
Doppelklick auf das Desktop-Symbol blitzte damit erst eine schwarze Box auf.
`GetConsoleProcessList` unterscheidet beides: genau ein Prozess an der
Konsole heißt, sie gehört uns.
**Folge für den Plan:** Kein neuer Etappen-Punkt — das ist Teil von V2-4 und
dort erledigt. `src/rippy/fenster.py` trägt die vollständige Begründung.
---
### Was jetzt noch fehlt, bevor gebaut wird