5d93476c01ed67d0ee18ea8fa799e4f2a9b6ccd4
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Felix RiestraandClaude Sonnet 5
|
5d93476c01 |
Add DWG-native constraint compatibility design doc
Hakan (upstream maintainer) asked for the sketch-constraint system to
persist using the constraint object model already exposed in acadrust/
cadcodec (Assoc2dConstraintGroup, AssocConstraintNode), so a file saved
by OpenCADStudio carries constraints AutoCAD/BricsCAD recognize as
their own native objects, not just an opaque custom XRecord blob.
Covers:
- The full ConstraintKind -> AssocConstraintNodeData mapping table,
grounded in build_constraint's actual refs shapes (the real contract,
not the doc comments).
- The geometry-node mapping for SketchRef (line/circle/arc/point
references) onto Line/BoundedLine/Circle/Arc/ImplicitPoint nodes.
- The AssocNetwork -> AssocAction -> Assoc2dConstraintGroup graph shape
actually needed, not just a flat data swap.
- A proposed additive persistence strategy: write both our own
OCS_SKETCH_CONSTRAINTS XRecord and the native graph, since our model
carries things (DrivingValue::Named) the native graph can't yet
losslessly express.
- Known gaps: Equal has no length/radius sub-kind split natively,
several AutoCAD constraint types we don't model at all, Tangent
involving an Arc (a pre-existing gap in the constraint system,
unrelated to DWG compatibility).
Three of five open questions are resolved against Autodesk's own
primary sources rather than left as inference: the ObjectARX 2012 SDK's
own C++ headers (mirrored on GitHub, Autodesk's own copyright notice
grants free use/distribution -- it's the SDK Autodesk publishes for
third-party interop) and Autodesk's live public ObjectARX reference
site. Confirmed: the associative network's dictionary key
("ACAD_ASSOCNETWORK"), the AcDb::ImplicitPointType enum settling how
SketchRef's point markers map to constraint geometry nodes, and that
AssocVariable's evaluator field can be left empty (Autodesk's own doc:
"the default evaluator for current acad version will be used"). Two
questions remain and need a real write-then-open test rather than more
reading: whether AutoCAD tolerates a partially-populated graph, and
DWG version gating on fields not yet checked.
Suggested staged approach: prove out Horizontal/Vertical on a single
Line first (sidesteps the value-dependency wiring), verify it opens
cleanly in real AutoCAD/BricsCAD or a DWG inspector, before writing
more of the graph on an unverified foundation. Design only -- no
implementation yet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
Felix RiestraandClaude Sonnet 5
|
7cddf31bcb |
Add named parameters, UI scale setting, OPTIONS/OP dispatch, and help manual
Named parameters (docs/named_parameters_design.md, stages 3-4): - ParameterTable (src/scene/named_parameters.rs): a document-wide table of named formulas, each resolved through a shared expression evaluator with cross-parameter references, cycle detection, and division-by-zero/parse error reporting. SketchConstraint::driving_param becomes DrivingValue (Literal | Named) instead of a bare f64, resolved at solve time by sketch_solve::build_constraint via Scene::named_parameters. - Persistence (src/scene/named_parameters_persist.rs): same lazy XRecord model sketch_persist.rs already established, synced around open/save. Bumps the sketch-constraint XRecord's own format version (1 -> 2) since DrivingValue's shape doesn't line up with a version-1 blob's bytes. - PARAMETERS command and its editor (src/ui/window/named_parameters.rs): add/remove/edit rows, live validation, duplicate-name detection: Apply defines the table and re-solves every constraint scope with a named-parameter-driven constraint (command_driver.rs). Distance/Angle constraint prompts (modules/draw/constrain/value.rs) now accept either a literal or an existing parameter's name, mirroring how the constraint's own value prompt already worked. - Undo scope-down carried over from this project's own established pattern (constraint-system stage 9): the geometry an Apply moves is one undo step, but the parameter table edit itself has no undo entry yet — a documented follow-up, not a silent gap. UI scale setting (src/app/settings.rs, app/mod.rs, ui/window/options.rs): a whole-interface scale percentage (50-200%), wired directly into iced's own per-window scale_factor hook rather than per-panel font-size plumbing, so it applies immediately to every panel, dialog, and the ribbon at once. Persisted alongside the existing lineweight-display-scale setting. OPTIONS/OP command dispatch (app/commands/view.rs, app/commands/mod.rs): OPTIONS was registered for autocomplete but had no dispatch arm — the Start-tab welcome screen's own button was the only way to reach it. Found live-testing the UI-scale setting, unrelated to that feature itself. "OP" is AutoCAD's own short alias. help/: a new self-contained static user-help manual (manual.md as the authored source, tools/build_help.py splits it into the committed static HTML pages plus search index) — not yet wired into the application. 64 new/updated tests across the named-parameters and constraint-prompt changes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Felix Riestra
|
e2d39b049d |
Merge branch 'main' into feature/parametric-constraint-system
# Conflicts: # src/app/automation.rs # src/app/mod.rs # src/ui/ribbon/widgets.rs |
||
|
Felix RiestraandClaude Sonnet 5
|
4c264b8c69 |
Port the PlanarEllipse tangent-geom variant and full OSNAP ellipse fix
Completes the OSNAP intersection port from
|
||
|
Felix RiestraandClaude Sonnet 5
|
44deee2ac9 |
Port 6 audit-found bugs from the upstream OSNAP fix branch
Ports the fixes from fix/osnap-circle-arc-ellipse-intersection (and this session's audit follow-up) onto this branch. All are independent correctness/reliability fixes, unrelated to the parametric-constraint- system work also in progress here. 1. OSNAP Intersection snap used a tessellated approximation instead of exact geometry (GitHub discussion #1052): a circle/arc always tessellates at a fixed 48 segments in the resident wire set regardless of radius or zoom, so every circle/arc intersection snap was off by construction. Added exact_circle_intersections, a closed-form, frame-independent circle/arc-vs-circle/arc solver, wired into both Intersection-snap code paths ahead of the tessellated sweep. This branch's TangentGeom predates the PlanarEllipse variant added upstream, so the ellipse/line generalization from the upstream fix isn't ported here — this covers the literal reported bug (a circle-circle case) using only variants this branch already has. 2. Unbounded MINSERT allocation: array_offsets() reserved one Vec element per array instance with row/column counts parsed as unchecked u16s — a corrupt 65535x65535 pair requests ~96 GiB. Fixed with a documented instance budget (20,000), enforced at both the load-time corrupt-entity filter and a render-graph failsafe. 3. MINSERT spacing was scaled by the block's own scale: insert_instance_transform composed the offset translation before the instance transform, so x/y block scale multiplied the row/ column spacing too. Fixed by orienting the offset with rotation + OCS only, then translating the already-scaled instance transform. 4. Automation "open" skipped the finalization (block-origin normalization, raster-path resolution, source_path) and corrupt- entity purge a UI open always runs. Added io::load_bytes_finalized(path, bytes), used by automation's "open" handler, which now also reports the purge count. 5. Material maps were uploaded without checking device.limits().max_texture_dimension_2d, unlike raster-image rendering (which already tiles to that limit). A mesh material is sampled by UV, so it can't use the same tiling trick — instead, upload_rgba_texture now downscales an oversized image before upload, falling back to the 1x1 material color if malformed. 6. Sketch-constraint persistence/undo, audit-found while reviewing this branch's own constraint system: - Clearing every constraint in a scope after a prior non-empty save left the stale XRecord in place, resurrecting the deleted constraints on the next load. materialize_sketch_constraints_for_ save now actively removes the XRecord when a scope goes back to empty. - ERASE removing an entity took its constraints with it (design doc's deletion policy), but sketch_constraints lives on Scene, outside document/document.objects, so nothing captured that mutation for undo — the erased geometry came back on undo, but its constraints didn't. refresh_sketch_constraints's deletion pass now records the touched scope's before-image into the same UndoRecording the entity removal rides in, threaded through a new sketch_constraints channel on DeltaSnapshot, so one undo restores both together. HistorySnapshot::Delta is now boxed (clippy flagged the resulting size skew across undo/redo stack variants). 31 new/adapted tests across all six fixes. Full workspace suite passes except the one pre-existing, unrelated font-test failure also present on main. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Felix RiestraandClaude Sonnet 5
|
63a74b19a9 |
Add persistent sketch-constraint system (ocs_gcs port) and named-parameters handoff docs
Ports FreeCAD's planegcs 2D geometric constraint solver to Rust as a new crates/ocs_gcs workspace member, and wires it into the document/scene model as a persistent SketchConstraintSet: Coincident, Horizontal/Vertical, Parallel/Perpendicular, Equal, Tangent, Distance, Angle and Radius constraints that re-solve live (including mid-drag, not just on release), render glyphs and a DOF badge, flag conflicts with a one-click resolver pill, and round-trip through save/load via an XRecord blob. Also includes docs/command_reference.md (a statically generated reference of every registered command and its prompt sequence) and docs/named_parameters_design.md + docs/backlog.md, which hand off the next queued feature (a named-parameter/expression table) and consolidate every deliberate scope-down and open gap found along the way, so a fresh session has a complete starting point. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Felix RiestraandClaude Sonnet 5
|
a39c7b8f71 |
macOS launcher: re-assert Accessory policy after handling an event
Handling a document-open Apple Event (a warm "Open With" while the app is already running) silently promotes this process from NSApplicationActivationPolicyAccessory to a normal foreground app — confirmed with lsappinfo, not assumed: its own entry flips from type="UIElement" to type="Foreground" the instant it handles a second Apple Event (a cold launch's own first event doesn't trigger this). That gave the launcher its own, contentless Dock icon sitting next to the real editor's, both apparently "the same app" to the user but actually two separate Dock entries. Re-set Accessory explicitly right after relaying, in the one place every open (cold fallback, document open, and reopen-while-running) already funnels through. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Felix RiestraandClaude Sonnet 5
|
24e9a7663d |
macOS launcher: handle reopen while already running with no window
Quitting the real GUI binary (Cmd+Q) leaves the launcher itself still running — that's by design, so it can keep relaying opens for the session. But reopening the app afterward (Dock icon, double-clicking it in Finder again) reactivates that same long-lived launcher process rather than triggering a fresh cold launch, since Launch Services still considers the bundle running. Neither of the delegate methods already handled covered that: applicationDidFinishLaunching: only fires once, at the launcher's own original cold start, and application:openURLs: only fires when a document was named. The net effect: the Dock icon would appear, but no window ever showed. applicationShouldHandleReopen:hasVisibleWindows: is exactly the callback AppKit fires for this reactivation case. Reproduced and verified the fix against the real sequence (cold launch, kill only the GUI process to simulate Cmd+Q, reopen) rather than assuming it from the delegate method's docs alone. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Felix RiestraandClaude Sonnet 5
|
e767507850 |
macOS: add a launcher shim so a cold Finder open also works (#1039)
The previous commit's Apple Event handler only ever catches an open sent to an already-running process. A cold double-click (app not running yet) still failed: every registration point tried inside the real binary — before app::run(), on the Subscription's first poll, even the literal first statement of main() — reliably caught a warm open but never the original cold-launch event. A raw AEInstallEventHandler in a separate, minimal, non-AppKit process (no winit/iced, just a manual CFRunLoopRunInMode pump) still missed it too, ruling out "the real binary's heavy dependency graph loading before main() wins the race" as the explanation. What does reliably catch a cold launch, verified against real Finder-equivalent opens: a from-scratch NSApplication with its own delegate implementing application:openURLs: — in a process where we own setDelegate: from the start, with no contention over the single delegate slot winit already claims. That has to be a separate process from the real GUI binary (only one -[NSApplication run] call can own a process), so src/bin/ocs_launcher.rs is now the .app's actual CFBundleExecutable: a small, dependency-light binary (no iced, wgpu, or cadkernel) whose only job is to catch the open and relay it. Relaying by replacing this process's image (exec, same PID) or by spawning a child and exiting turned out to both be dead ends: Launch Services tracks "the running instance of this bundle" by the Application Serial Number it handed out to whichever process it actually launched — this launcher, not whatever it execs into or spawns. Once the launcher's own ASN stopped pointing at a live, listening process, every later open Finder tried to deliver silently went nowhere (measured with lsappinfo against a real second "Open With", not assumed). So the launcher now stays running for the app's session — invisible, via NSApplicationActivationPolicyAccessory, since it owns no window — and relays every open (cold or warm) over the same channel a second CLI invocation already uses: io::single_instance. That relay only worked once single_instance's rendezvous key stopped being computed from the running executable's own path. That was fine when one binary always did the job, but the launcher and the real binary are different executables and independently computed different ports, so they could never find each other. Anchor the key on the enclosing .app bundle instead, shared by both. packaging/build_macos_signed.sh and .github/workflows/release.yml now build ocs_launcher and place it at Contents/MacOS/OpenCADStudio (the CFBundleExecutable Info.plist already names), with the real GUI binary renamed to Contents/MacOS/OpenCADStudio-App alongside it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Felix RiestraandClaude Sonnet 5
|
b617734d5c |
macOS: catch a Finder open aimed at the already-running app (#1039)
Double-click / "Open With" never puts the file on argv — Finder always delivers it as a kAEOpenDocuments Apple Event instead, which nothing in this app listened for, so it just showed "cannot open files in this format" even though the file association itself was registered correctly. The standard fix, implementing application:openURLs: on this app's own NSApplicationDelegate, isn't available here: winit already installs its own delegate to own window/lifecycle events, NSApplication has exactly one delegate slot, and winit's class doesn't implement the open-document method. This bypasses the delegate protocol and registers directly with the lower-level Apple Event Manager (AEInstallEventHandler) instead — the same mechanism AppKit's delegate forwarding is itself built on, and independent of who owns the delegate. Registration happens on the iced Subscription's first poll rather than in main() before app::run() — registering earlier gets silently overwritten by winit's own NSApplication startup, confirmed by testing against a real `open -a` rather than assumed from Apple's docs. This handles a file opened while the app is already running. A cold launch (app not running yet) needs a different mechanism, in the following commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |