Neue Masslinie (shape:"dimension"): zwei Punkte + Lage der Masslinie. Folgt
der Norm statt DIN-Gewohnheiten: Massbegrenzungslinien als Massstriche
(doppelte Strichstärke, keine Pfeilspitzen), Masszahl mit Komma-
Dezimaltrennzeichen, nie kopfüber lesbar (dreht sich automatisch). Die
Masszahl wird nicht gespeichert, sondern immer aus dem aktuellen Abstand der
beiden Punkte abgeleitet — bleibt beim Griff-Ziehen automatisch korrekt.
Drei Griffe (beide Endpunkte + ein Griff auf der Masslinie zum Verschieben
des Abstands), Verschieben/Rotieren, Georef-Rebase und Plan-Einpassen
entsprechend erweitert.
Nutzer-Wunsch: "bei Kreisen wäre ich froh wenn Kreismittelpunkte und
0/90/180/270 Grad auch snappen." Fund: computeSnap() (tools/snapping.ts)
kannte das schon vollständig (Center- + Quadranten-Fang für Kreis/Bogen,
Bogen nur innerhalb seiner Winkel-Spanne) -- gesteuert über
`settings.center`, das im Modell aber auf `false` stand UND im Footer
(StatusBar SnapControl) gar keinen Schalter hatte. Ein bereits fertig
gebautes Feature war dadurch komplett unerreichbar.
DEFAULT_SNAP.center jetzt `true`; neue Checkbox "Kreismitte/Quadranten
(0/90/180/270°)" im Fang-Popover der Statusleiste (analog den übrigen
Snap-Arten), damit es wie alle anderen auch abschaltbar bleibt.
tsc/vitest 940/940 grün (keine bestehenden Tests setzten auf
center:false als Default).
Erweiterung des Hover-Teilpunkte-Features: bisher rein visuell im
Auswahl-Ruhezustand (vorheriger Commit). Nutzer-Wunsch: "wenn der
Snappunkt eines neuen Elements auch [z. B. 200ms] auf der Linie ist,
sollten die Teilpunkte auch für eine gewisse Zeit angezeigt werden und
snapbar sein. Aber nur dann!" -- also auch während des Zeichnens
(Command-Engine, Legacy-Werkzeuge, Griff-Ziehen, Transformieren), aber
bewusst NICHT dauerhaft (sonst würde jede N-tel-Position jeder Linie
den Fang-Kandidatenraum überfluten).
computeSnap() (tools/snapping.ts) bekommt eine modulweite Verweil-
Erkennung (wie lastCoalesceKey in projectSlice.ts) -- bewusst
MODULWEIT statt in SnapInput, weil computeSnap von mehreren
unabhängigen Stellen aufgerufen wird (Command-Engine-Snap-Callback,
Legacy-tool.onMove, Transform, Griff-Editieren) und der Verweil-
Zustand aufrufer-übergreifend gelten muss, damit "verweilt der Cursor
lange genug auf DERSELBEN Linie" unabhängig davon erkannt wird, WELCHER
Aufrufer gerade snappt. Sobald erreicht, werden die `hoverDivideCount`-
gleichen Teilpunkte der verweilten Strecke als normale Snap-Kandidaten
(neuer SnapKind "divide", Priorität wie Mittelpunkt) berücksichtigt --
bei einem Streckenwechsel setzt sich die Verweildauer sofort zurück.
Neuer Marker-Glyph (gefüllte Raute) in SnapMarker (overlays.tsx) für
kind "divide" -- bewusst anders als Mittelpunkt (Linie) und Auf-Kante
(Raute nur Umriss), damit nachvollziehbar bleibt, warum es gerade dort
fängt.
+3 Tests (Fake-Timer-gesteuert: kein Fang vor der Verzögerung, Fang
danach exakt auf dem Drittelpunkt, Verwerfen bei Linienwechsel
zwischendurch). tsc/vitest 925/925 grün.
Neues Feature (Nutzer-Wunsch): ruht der Cursor im Auswahl-Ruhezustand
(kein Werkzeug/Drag) länger als eine einstellbare Zeit (Default 300ms)
auf einem 2D-Linien-Segment, erscheinen dessen gleiche Teilpunkte kurz
mit Akzentfarbe -- bei 2 Teilen (Default) nur der Mittelpunkt, bei 3/4/…
entsprechend mehr. Reine Sichtbarkeits-Hilfe, kein neues Snap-Ziel.
Verzögerung (ms) und Teile-Anzahl sind unten im Footer einstellbar, im
bestehenden Fang-Popover (StatusBar.tsx SnapControl) als zwei weitere
Zahlenfelder -- neue Felder hoverDivideDelayMs/hoverDivideCount auf
SnapSettings (tools/types.ts), NICHT an snap.enabled gekoppelt (eigenes,
vom Fang unabhängiges visuelles Feature).
PlanView.tsx: neue nearestLineSegment()-Suche (dieselbe Bildschirm-Nähe-
Logik wie pickDrawing, liefert aber die zwei Endpunkte des konkret
gehoverten Segments einer Polylinie, nicht nur die drawingId). Ein
Timer verankert/verwirft die Anzeige bei Segment-Wechsel; die beiden
neuen Props (hoverDivideDelayMs/hoverDivideCount) werden wie snapColor
durch viewportContent.tsx bis zu PlanView durchgereicht.
tsc/vitest 922/922 grün. Manuell in der App zu prüfen (Pointer-Hover
ist nicht automatisiert testbar, wie die übrigen Griff-Interaktions-
Fixes dieser Session).
ResourceManager.tsx, generatePlan.ts und toWalls3d.ts sind nach Bauteil-
Domäne in src/ui/resourceManager/, src/plan/generatePlan/ und
src/plan/toWalls3d/ aufgeteilt (reine Verschiebung, keine Verhaltens-
änderung). App.tsx verliert weitere Handler-Gruppen an eigene Hooks
(useExportHandlers, useImportHandling, useKeyboardShortcuts) sowie
Hit-Testing an src/viewport/planHitTest.ts.
Unbenutzte Rust-geometry-Crate (durch WASM-Joins abgelöst) sowie der alte
OCCT/HLR-Schnitt-Spike (hlr.ts/occt.ts, vite occt-Aliases) entfernt.
Neu: PDF-Import als Rasterbild (src/io/pdfImport.ts) + gemeinsamer
Bild-Asset-Helfer (src/io/imageAsset.ts) für Plan- und Layout-Bilder.
tsc -b sauber, vitest 891/891 grün.
VW-Feinschliff (Nutzer-Screenshots):
- Rechteck (2-Punkt + Zentrum) zeigt Δx/Δy vorzeichenbehaftet statt
Diagonale+Winkel (deltaHud; Zentrum = volle Rechteckmasse). Die
width/height-Tab-Felder erscheinen im HUD als Δx/Δy.
- Führungslinie des Winkelrasters läuft jetzt weit über den Cursor hinaus
(quer über den Ausschnitt statt 40 px).
- Winkelbogen ergänzt: gestrichelter Bogen von der horizontalen 0°-Referenz
(dezentes Lachsrot, VW-Anlehnung) zur Strahlrichtung, Badge sitzt am
halben Winkel aussen am Bogen.
737/737 grün; headless verifiziert (Linie 45° + Rechteck-Δ).
Beim Zeichnen erscheinen Länge + Winkel direkt am Cursor (L:/W:-Kästchen),
gängige Winkel (15°-Vielfache) rasten weich ein — mit Winkel-Badge und
gestrichelter Führungslinie. Vorrang: Objekt-Snap > Shift/Ortho > Winkelraster
> Raster. Toggle + Toleranz in der Fang-Leiste. Konflikt tools/types.ts:
erweitertes hud-Feld + measure-Feld koexistieren.
# Conflicts:
# src/tools/types.ts
Beim Zeichnen erscheint jetzt direkt am Cursor ein blau umrandetes
Massband-Kästchen mit Länge/Winkel (L: 3.118m W: 60.000°, Winkel im
Bereich (−180,180]) statt nur in der Befehlszeile. Zusätzlich rastet
der Zugwinkel weich auf gängige Winkel (15°-Vielfache, Toleranz per
Default 2.5°) ein, sobald kein Objekt-Snap greift — mit gelblichem
Winkel-Badge und einer über den Cursor hinaus verlängerten, gestrichelten
Führungslinie (Vectorworks-Vorbild).
- tools/types.ts: ToolDraft.hud um length/angleDeg erweitert (text bleibt
für Befehle ohne L/W-Paar), neuer segmentHud()-Helper.
- tools/snapping.ts: neue reine Funktion snapCommonAngle() + Einbindung in
computeSnap (Objekt-Snap > harter Ortho-Zwang > weiches Winkelraster >
Raster). Neues SnapSettings-Feld commonAngles + commonAngleTolerance,
neuer SnapKind "angle".
- ui/StatusBar.tsx: Toggle + Toleranz-Eingabe in der Fang-Popover.
- plan/PlanView.tsx: DraftHud- und AngleGuide-Overlay (screen-space,
zoomunabhängige Größe); die Winkel-Info reitet auf draft.snap mit.
- i18n: snap.commonAngles / snap.commonAngleTolerance (de/en).
- snapping.test.ts: snapCommonAngle-Fälle (exakt/Toleranz/Bereich/
15°-Raster/Projektion) + Objekt-Snap-Vorrang vor dem Winkelraster.
Das Mess-Werkzeug wird von der reinen Strecke zum Polygonzug:
- Jeder Klick setzt einen weiteren Stützpunkt; angezeigt werden letztes
Segment (Länge · Winkel), aufsummierte Pfadlänge und — ab 3 Ecken —
die umschlossene Fläche (Gauss).
- Die Messwerte erscheinen dauerhaft im Objekt-Info-Panel (neuer
Abschnitt „Messung"), nicht nur flüchtig am Cursor-HUD. Kanal:
ToolDraft.measure → PanelHost.measurement → ObjectInfoPanel.
- Rechtsklick/Enter beendet den aktuellen Pfad und armiert sofort einen
neuen (mehrere Messungen nacheinander); Rechtsklick auf leerem Pfad
bzw. Esc beendet das Werkzeug.
+4 Tests (Segment/Winkel, Summe/Fläche, Ketten-Verhalten). tsc sauber.
Neuer GPU-Renderer fuer den Grundriss (src/plan/glPlan/): Earcut-Tessellierung
(konkav-faehig), gehrte Linienzuege (Miter), echte Papier-mm-Strichbreiten im
Massstab (repliziert den SVG-printStrokeVb-Pfad), Hybrid mit scharfem SVG-Text-
Overlay. GPU ist der Standardpfad; der SVG-Renderer bleibt automatischer Fallback,
falls WebGL2/Shader nicht verfuegbar sind. Imperativer Pan (rAF + CSS-transform)
fuer fluessige Interaktion ohne React-Re-Render je Frame.
Enthaelt zudem den bisher nicht committeten Arbeitsstand des Browser-BIM
(Oeffnungen, Treppen, Raeume, Decken, DXF-Export, Materialbibliothek, Kontext-
Import, Tauri-Compute-Boundary-PoC).
Standalone-Browser-Port von DOSSIER. Enthaelt das semantische Modell mit
Plan-/3D-Ableitung, Zeichen- und Editierwerkzeuge, Rhino-artiges Befehlssystem,
dockbares Panel-System, Resource-Manager, DXF/.lin/.pat-Import, i18n (de/en)
sowie Projektdokumentation und Probe-Harness.
karim