SeymourBETAUpdate 2.19
6.6.2026
v2.19.0BETA
Seymour
SeymourMODEL VIEWER IM EDITOR EINGEBETTET (kein Browser): nativ WebView2 in einem Panel
- Phase 2 der Plot-Twist: der GLEICHE three.js-Viewer der 816 Modelle läuft jetzt INNERHALB des Editor-Fensters, in einem Panel — ein neuer "Model Viewer (Embedded) 🐉"-Button in der Extras-Karte →
SetModulezeigtModelViewerEmbedded_Control, das eine Edge WebView2 überNativeControlHosthostet (win32-Interop: Child-HWND +CoreWebView2Controller, Bounds synchronisiert inArrangeOverride, HiDPI viaRenderScaling). Es nutzt die bereits installierte WebView2-Evergreen-Runtime (kein Chromium-Bundle —Microsoft.Web.WebView21.0.2592.51, ~wenige MB; NICHT das schwere CEF, das ~100MB hinzufügen würde). Das Panel startet denselben HTTP-Server (ModelViewerLauncher.EnsureServerAndGetUrl, Port 8767, cache-busted) und navigiert das WebView dorthin; „Reload" + „Open in Browser"-Buttons (Fallback).Program.cs/AppBuilder unberührt. Build 0 Fehler. In einem isolierten Worktree-Spike bewiesen (bewertet: kompiliert + 0 neue Warnungen) vor dem Port nach main. Phase 1 (Browser, v2.18.0) bleibt als Fallback. Owner-Entscheidung nebenbei: die Galerie öffnet in der sauberen REST-Pose (Animation opt-in) — wir haben das Offline-Animation-Whack-a-mole gestoppt; echte Animation = mocap später (eingereiht). DocFFX_MODELVIEWER_EDITOR_2026-06-06.md. \
v2.18.1
v2.19.1BETASeymour
SeymourMAGIC VIEWER IN DEN EDITOR eingebettet (kein Browser): nutzt das -WebView2 wieder v2.19.0
- Direkte Antwort an den Eigentümer („die Idee war IMMER im Editor; einen Browser zu öffnen ist dumm"): „Magic Viewer (Web)" öffnet keinen externen Browser mehr — die Navigation wechselt jetzt per
SetModulezumMagicViewerEmbedded_Control, ein WebView2-Panel im Fenster. Es nutzt den GEMEINSAMENWebView2Hostwieder, den der Model Viewer in eingeführt hat (eine Embedding-Infrastruktur für beide Viewer, keine Duplikation). Neu v2.19.0:MagicViewerEmbedded_Control/DataModel+MagicViewerLauncher.EnsureServerAndGetUrl(startet den lokalen HTTP-Server 8766 + Cache-Bust und navigiert das WebView dorthin); Reload + Open in Browser-Buttons (Fallback). Koordination (2 Chats an einem Branch): ich wartete, bis der andere ChatWebView2Host() committete, um sauber darauf aufbauen zu können — kein kaputter Baum; die Code-Audit-Findings ihrer lane liegen in v2.19.0HANDOFF_CODE_AUDIT_HD_MODELS_2026-06-06.md. Build 0 Fehler, Editor startet ohne Crash neu. \
v2.19.0
v2.19.2BETASeymour
SeymourEmbed-Fix: die WebView2 FÜLLT das Panel und folgt der Größenänderung (gilt für BEIDE Viewer)
- Auf dem Bildschirm renderten die eingebetteten WebView2 nur in einer Ecke (~67% auf einem hiDPI-Display) mit schwarzen Rändern und folgten nicht der Editor-Größe. Ursache:
SyncControllerBoundsmultiplizierteBounds × RenderScaling, während Avalonia das Host-Fenster AUCH dimensioniert → DPI-Doppelzählung (Inhalt bei ~1/scale). Behoben im gemeinsamenWebView2Host(fixiert also Model Viewer v2.19.0 UND Magic Viewer auf einmal v2.19.1): Die WebView aus dem echten Parent-Client-Rect (GetParent+GetClientRect, keine Skalierungs-Mathematik) + Re-Sync bei jeder Größenänderung (EffectiveViewportChanged+ ein verzögertesArrangeOverride-Post beiDispatcherPriority.Background, damit es läuft, nachdem Avalonia den nativen Host neu positioniert hat). Build 0 Fehler. On-Screen-Verifikation = das Auge des Eigentümers. \
v2.19.1