5 Commits

Include renames

Author	SHA1	Message	Date
HitonabiandClaude Opus 5	827910fd63	feat(v5): eigenes Fenster ohne Windows-Rahmen + Layout skaliert mit ... Zwei Befunde des Commanders (01.09.2026): 1. "Momentan ist alles nach links gerueckt, nichts skaliert mit der fenstergroesse und es ist alles gequetscht." Ursache gefunden: <main> hatte WEDER Zentrierung NOCH Maximalbreite, die Karten darin aber einen harten Deckel von max-w-2xl (672 px). In einem 1280er Fenster klebte damit alles am linken Rand und rechts stand nichts. Behoben: * <main> und Kopfzeile teilen sich mx-auto max-w-[1600px] mit mitwachsendem Innenabstand — der Inhalt ist mittig und nutzt die Breite. * Der 672-px-Deckel der Einstellungs-Spalte ist weg. Drei Encoder-Felder stehen jetzt nebeneinander statt untereinander. * Die Sektionswahl der Einstellungen wird im schmalen Fenster zur Zeile ueber den Karten (lg:flex-row), statt eine 176-px-Spalte vom ohnehin knappen Platz abzuziehen. * Info-Kacheln der Laufwerks-Karte: zwei Spalten schmal, vier breit. * Startgroesse 1000x700 -> 1280x820, Mindestmass 720x480 -> 860x560. 2. "waere sogar richtig cool wenn du den rahmen wegbekommst" frame:false, und die Kopfzeile IST jetzt die Titelleiste: Minimieren / Maximieren / Schliessen sitzen oben rechts in Windows-Massen (46x32), gezogen wird an der Kopfzeile, Doppelklick maximiert. Groesse aendern bleibt moeglich — Electron setzt fuer rahmenlose Fenster unter Windows weiter WS_THICKFRAME (thickFrame, Standard true), die Kanten ziehen also wie gewohnt. Schliessen nimmt GENAU den Weg des alten Fensterkreuzes (fenster.close() -> der bestehende close-Horcher versteckt nur): Rippy lebt im Tray weiter, ein laufender Rip merkt davon nichts (Paragraph 4.1 Punkt 3). Die Ziehflaeche ist .ziehbar in stil.css; alles Bedienbare darin traegt .nicht-ziehbar, sonst verschluckt der Griff den Klick. fensterMaximiert im HauptStatus entscheidet ueber das Knopf-Symbol und wird auch bei Doppelklick/Tastenkuerzel nachgefuehrt (maximize- und unmaximize-Horcher). Nachgemessen mit dem Smoke-Beweis: beweise/ui-513-uebersicht.png (kein Rahmen, eigene Knoepfe, Inhalt ueber die volle Breite) und beweise/ui-513-einstellungen.png (drei Encoder nebeneinander). 230 Tests gruen, Typpruefung sauber. Version 5.1.3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 18:07:45 +02:00
HitonabiandClaude Opus 5	c0a7618e33	feat(v5): Update sichtbar machen — Meldung, Knopf und Changelog ... Der Commander: "irgendwie fehlt in rippy selbst der Button 'Auf updates pruefen' oder auch direkt beim start ne meldung 'ey jo update verfuegbar' - waere noch cool wenn das kommt inkl. changelog". Zu Recht. Der Kanal arbeitete korrekt, war aber UNSICHTBAR: Der Update-Stand lag im Haupt und wurde nur beim Laden des Fensters EINMAL mitgeschickt. Fand die Pruefung etwas, aenderte sich am Bildschirm nichts; der einzige Hinweis war ein Satz unter "Update-Adresse", den man kennen musste, um ihn zu finden. Was jetzt da ist: * Eine goldene Karte OBEN in der Uebersicht, sobald etwas gefunden wird — mit neuer Versionsnummer, der laufenden Version, Ladefortschritt und den Aenderungsnotizen. Dazu ein Windows-Toast beim Fund. * Knopf "Jetzt auf Updates pruefen" in den Einstellungen. Waehrend eines Rips ist er AUS, mit Begruendung im Tooltip — Rippy sucht dann bewusst nicht (Paragraph 6.8). * Knopf "Jetzt neu starten und installieren" auf der Karte, sobald das Paket geladen ist. Sagt NEIN mit Grund statt still nichts zu tun (R4). * Der Stand meldet JEDE Aenderung sofort ans Fenster (setzen() ruft immer beiAenderung) — kein Zustand mehr, den niemand erfaehrt. Der Changelog kommt aus bau/release-notes.md. An der installierten Bibliothek geprueft statt aus dem Kopf (Regel D): app-builder-lib out/publish/updateInfoBuilder.js getReleaseInfo() liest genau diesen Dateinamen und legt den Inhalt als releaseNotes in latest.yml; builder-util-runtime deklariert UpdateInfo.releaseNotes als "string | Array<ReleaseNoteInfo> | null". neuerungenText() vertraegt beide Formen, wirft HTML-Marken raus und deckelt die Laenge. UpdateStand ist jetzt EINE Definition in gemeinsam/nachrichten.ts, die sich Haupt und Fenster teilen. 230 Tests gruen (vorher 225), Typpruefung sauber. Version 5.1.2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 17:51:38 +02:00
HitonabiandClaude Fable 5	9fa3df500d	feat(v5): Etappe W-6 — Setup, Selbst-Update, Erst-Einrichtung, Lizenzen ... electron-builder → NSIS: EIN RippySetup-<version>.exe, pro Benutzer, ohne Adminrechte, eigenes Icon (PNG-basiertes ICO selbst gebaut). extraResources: die MITGELIEFERTEN Werkzeuge (HandBrakeCLI GPL-2, flac.exe MIT libFLAC.dll — die Ohne-DLL-Falle aus § 9) samt Lizenztexten und Quellverweisen (bau/lizenzen, Entscheid 9); vendor/ liegt nicht im Git (74 MB), Befuellung steht in BAUEN.md. Der Kern findet die mitgelieferten Werkzeuge ueber RIPPY_VENDOR (resourcesvendor) VOR allen anderen Suchwegen. haupt/update.ts (§ 6.8): electron-updater gegen das oeffentliche Gitea (festes Tag 'aktuell' als Rueckfallebene, Entscheid 6) — NUR https (http wird ABGELEHNT; Regel-Tests), NIE waehrend eines Rips (der Haupt kennt die aktiven Vorgaenge), Fehlschlaege still aber ablesbar (letzte erfolgreiche Pruefung im Status), installiert beim naechsten Start. haupt/autostart.ts: HKCU-Run ueber app.setLoginItemSettings, Toggle in den Einstellungen. Erst-Einrichtung (§ 6.9) im Programm: 5 Schritte, NUR ein Fehler blockiert (kein Laufwerk = Warnung, MakeMKV-Pflicht mit Klartext-Weg). GEBAUT UND GEMESSEN (30.08.2026): - dist-setup/RippySetup-5.0.0-w0.exe — 130,8 MB, SHA-256 07D39D6BAB74A47C21AA53D847FB5A5DB6990AE9FA1CBC7BE814B51050883115, plus .blockmap. - MESSUNG: Die Update-Auskunft heisst bei Vorab-Versionen nach dem KANAL (w0.yml) — erst ein Release ohne Suffix erzeugt latest.yml (steht jetzt in BAUEN.md). - Das GEPACKTE Programm (win-unpacked, asar + resources) besteht den Smoke: SMOKE OK, und der Screenshot zeigt die Erst-Einrichtung — das Bild eines frischen Rechners. Bewusst offen (SAVEPOINT): die automatische MakeMKV-Beschaffung (beschaffen.ts — Download+Installer-Start braucht einen Live-Test); das Setup NENNT den Weg klar. 185 Tests gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 19:03:40 +02:00
HitonabiandClaude Fable 5	c78ff22ab7	feat(v5): Etappe W-5 — Oberflaeche: Tray, Toasts, Taskleiste, Einstellungen, Bibliothek ... haupt/: tray.ts (Symbol mit Zustand, Kontextmenue, Fenster zu = weiter- laufen, Beenden nur noch gewollt), Windows-Toasts bei Disc erkannt / fertig / Fehler (Klick holt das Fenster), Taskleisten-Fortschritt (setProgressBar, Fehlermodus), echter Windows-Ordnerdialog per IPC. Eigenes Icon (bau/icon.png + tray.png, Disc-Optik). Kern: Einstellungen lesen/schreiben NUR ueber die eine Quelle (§ 6.7, Whitelist der Schluessel), Werkzeug-Auskunft (Katalog + gemessene HandBrake-Presets/Backends), Bibliothek in db.ts (Schema v2 — fingerprint, Titel, Groesse, Ort, Dauer), Duplikat-Erkennung beim Einlegen (§ 6.6: 'schon einmal gerippt am …' als disc-info + Toast), Pipeline traegt fertige Vorgaenge ein. Fenster: drei Bereiche (Uebersicht / Einstellungen / Bibliothek). Einstellungen: Ablage mit Durchsuchen-Dialog, Kompression je Disc-Typ (Preset-Liste VOM eigenen HandBrake gemessen, 'NICHT komprimieren' waehlbar), Sprachlisten, TMDb/OMDb-Keys, Medienserver, Werkzeug-Stand mit Klartext (gefunden/fehlt + Folgen). Bibliothek als Tabelle. Der Smoke-Screenshot zeigt nebenbei den Ernstfall in schoen: Das Laufwerk ist nach dem rc11-Vorfall inzwischen auch am Storage-Stack in 'unknown' gekippt — und die Kachel zeigt den ZUGRIFFS_GRUENDE-Klartext samt Abhilfe statt eines stummen Zustands. 165 Tests gruen, Smoke gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:47:39 +02:00
HitonabiandClaude Fable 5	c539e65cd2	feat(v5): Etappe W-0 — das Geruest steht ... Electron 44 + TypeScript, drei Prozesse (haupt / kern als utilityProcess / fenster mit React), Nachrichten-Schema mit Pruef-Funktionen, node:sqlite als einzige Datenbank-Stelle (kern/speicher/db.ts, § 6.7), Prozess-Leine im Haupt (Job Object aus beweise/leine.js — Begruendung fuer den Ort im Dateikopf), MessagePort direkt Fenster<->Kern, Einzelinstanz-Sperre, Kern-Neustart-Wache, strikte CSP im gebauten Fenster. Wächter-Tests nach § 4.3: koffi nur an zwei benannten Orten (R1), kein leerer catch und kein catch-mit-Leerwert (R2/R4), kein HTTP-Server (§ 4.1), node:sqlite nur in db.ts (§ 6.7). Dazu Datenbank- und Schema-Tests: 18/18 gruen, Typpruefung in drei Kontexten. Der W-0-Beweis (npm run smoke, echtes Programm): SMOKE: OK — fenster=geladen kern=pid:13676,node:24.18.1 datenbank=ok leine=gesetzt pong=ok version=5.0.0-w0 Nachgemessen ausserdem: taskkill /F auf den Haupt-Prozess (ohne /T, der Absturz-Fall aus rc10) — der Kern stirbt mit. Bau-Fallen dokumentiert (BAUEN.md): npm 11 blockt Electrons Install-Skript (§ 3.5), plugin-react 6 verlangt Vite 8 (deshalb 5.2), TypeScript bewusst auf 5.9.3 gepinnt statt tsgo 7. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 16:53:30 +02:00