Double-clicking a drawing started a whole second copy of the app. Now it
lands as a tab in the editor already open, and that window comes forward.
The election is the bind itself: every GUI launch tries a deterministic
per-user loopback port, and the OS grants it to exactly one process and
releases it on any death, SIGKILL included. Nothing to reap, no PID to
probe, no stale lock after a crash. The winner serves the port from an
iced subscription; the loser checks it is talking to a matching editor,
hands the paths over and exits. Every surprise — no answer, a stranger on
the port, a timeout — boots a normal window, i.e. the old behaviour: the
feature can degrade, but it cannot lose the file.
The gate in main is positional, after every headless mode has returned.
The plugin runner is this same binary re-spawning itself, so a flag list
would rot the first time a mode is added; a position cannot.
Handing a drawing over that is already open switches to its tab instead
of loading a second copy, comparing resolved paths so a symlink or a
`..` hop is still recognised as the same file.
`opening` is a single slot that a second open would overwrite, and
on_file_opened drops any result arriving once it is clear — so drawings
handed over at once would silently vanish. They queue in pending_opens,
drained from every path that clears the slot, error and cancel included.
Exec becomes %F so one launch takes the whole selection; the CLI takes a
list and boot fans it out through the same door. --new-instance forces a
separate process; --read-only / --script / --new always get their own.
Not reused: the automation server. It dispatches arbitrary commands and
writes arbitrary paths, and its open replaces the active tab's document
in place — publishing that on a port every local process can reach would
be unforced privilege escalation. Only its JSON-lines framing is shared.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
WebGL2 has no vertex/fragment storage buffers, so the batched storage-buffer
hatch renderer (hatch_gpu) is disabled on wasm and real hatch fills never
rendered on the web build — the pick highlighted the boundary and the command
then appeared to cancel (issue #204).
Add a wasm-only per-hatch renderer (hatch_web_gpu + hatch_web.wgsl) that packs
the variable-length boundary / family / dash arrays into one RGBA32F data
texture read with textureLoad, instead of the fixed-size uniforms of the
wipeout path. This removes the MAX_FAMILIES (16) / MAX_HATCH_BOUNDARY_VERTS
(1024) / MAX_DASHES (128) caps, so every hatch — solid, gradient, and
arbitrarily complex line patterns — renders on the web. The fill algorithm
(in_polygon, per-family line/dash/dot, gradient, LOD, double-single vertex
transform) is identical to the desktop path; only the array ACCESS changes.
Pattern phase is anchored at world_origin with the boundary stored raw, and
scale / gradient-range clamped, to match the desktop batched renderer exactly.
Native (hatch_gpu + hatch.wgsl) and the wipeout mask renderer are untouched;
the new module and pipeline are gated on target_arch = "wasm32".
Also silence the resulting (and pre-existing) wasm-only dead-code warnings for
native-only paths so both the native and web builds compile clean.
Closes#204.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Round-trip a raster preview through the DWG's embedded preview slot and
surface it to the OS file managers, so drawings show their contents in
Explorer / Finder / Nautilus instead of a generic document icon.
OCS:
* io::thumbnail — rasterize the scene to a BMP DIB on save (embedded via
acadrust's new Preview type) and read it back on open for the Start
page recent list; `--dwg-thumbnail IN OUT SIZE` CLI extracts a badged
PNG for external thumbnailers.
* io::file_association::install_thumbnailer — self-install the OS
integration on startup: Linux writes a .thumbnailer + hicolor mimetype
icons; Windows registers the IThumbnailProvider DLL under HKCU.
Shared core:
* crates/dwg-thumbnailer — lean (image-only) preview extractor + the
`badge_dwg` full-width "DWG" band, used by every platform so the
ribbon is single-sourced. Ships an rlib+staticlib.
* crates/dwg-thumbnailer-win — IThumbnailProvider COM in-proc server
(cfg(windows), CI-built as a workspace member).
* macos/ — QuickLook thumbnail extension (Swift + C-ABI bridge to the
core staticlib), assembled into a .appex.
Icons & packaging (single SVG source -> per-platform assets in CI):
* assets/mimetypes/image-vnd.{dwg,dxf}.svg — themed file icons.
* packaging: WiX ships dwg/dxf.ico + the thumbnail DLL and points the
ProgIds at them; Info.plist gets CFBundleTypeIconFile + the QuickLook
extension in Contents/PlugIns.
* release.yml — generate .ico (Windows) and .icns (macOS) from the SVGs,
build the QuickLook .appex, and bundle everything.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The v0.7.0 web (GitHub Pages) release failed to compile under
--no-default-features. Two symbols leaked into the wasm build:
* `solid_section` (SECTION command) used truck-meshalgo directly
(`triangulation`/`extract_interference`), but that crate is gated
behind the `solid3d` feature which is off on wasm. Gate the function
with `#[cfg(feature = "solid3d")]` and add a stub for builds without
it, mirroring `solid_model::boolean`.
* `register_as_handler` was `#[cfg(not(wasm32))]` while its caller
`set_default_app_blocking` was not, so wasm couldn't resolve it. Drop
the wasm gate; the existing non-win/lin/mac arm already returns `Ok`
on wasm, matching `unregister_handler`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Drop the every-launch (re)registration thread. File association is now set up
once via the first-launch prompt (Yes → register + set default; No → decline,
persisted as file_assoc_enabled) and managed afterwards by the FILEASSOC
command. set_default_app now registers the handler entries (.desktop / mime /
ProgIDs) itself before asking the OS to default to us, since boot no longer
does — so the default never points at a missing handler.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`FILEASSOC 1` (re)registers the app as a .dwg/.dxf/.bak handler; `FILEASSOC 0`
unregisters it (removes the .desktop + CAD mime package on Linux, the per-user
registry keys on Windows); bare `FILEASSOC` reports the current state. The
choice persists (file_assoc_enabled) and gates the every-launch
re-registration, so turning it off stays off across restarts.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Save: overwriting an existing file first copies it to a sibling <name>.bak
(default on; toggle with the ISAVEBAK command, persisted in settings).
- Open: .bak is a first-class type — the Open dialog lists it and the loader
detects DWG vs DXF from the file's leading magic bytes (the extension hides
the real format).
- File association registers .bak too, every launch (so users who associated
earlier get it automatically): Windows via the registry; Linux via a
high-priority shared-mime-info magic that resolves DWG/DXF content under the
.bak extension, with the generic *.bak glob claimed only once the app is the
default DWG handler — so it never hijacks other apps' backups.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gate target-specific code so neither build warns about the other's items:
native-only helpers (view, window icon, file dialogs, file association, plugin
host/guard/registry, self-update) are cfg'd to non-wasm; the wasm-only font
fallback (script_of / cjk_lang / request) is cfg'd to wasm. Drop an unused mut,
allow the few genuinely-conditional dead items (mesh_click_hit, GPU layout
helpers, parity stubs), and gate the embedded PlotSettings-unrelated dead
constants. Both targets now build clean (only the unavoidable nom/quick-xml
future-incompat dependency notice remains).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Both the MSI and the portable build were missing Applications\OpenCADStudio.exe\
DefaultIcon, causing a blank generic icon in the "Open with" context-menu list
and the "Choose another app" picker.
- packaging/windows/main.wxs: add Applications\OpenCADStudio.exe\DefaultIcon
(+ FriendlyAppName, shell\open\command, SupportedTypes) to the
DefaultPrograms component for MSI installs (HKLM).
- src/io/file_association.rs: add DefaultIcon to the Applications\
OpenCADStudio.exe block written at runtime for portable builds (HKCU).
https://claude.ai/code/session_01DFVSKgViFaxEjZD2KsTdtt
The .desktop file used a named icon (Icon=io.github.HakanSeven12.OpenCadStudio)
but the icon file was never written to the XDG icon theme directory, so file
managers and the "Open with" picker fell back to a generic blank document icon.
install_icon() now writes assets/logo.svg (embedded at compile time) to
~/.local/share/icons/hicolor/scalable/apps/{APP_ID}.svg alongside the
.desktop file, and runs gtk-update-icon-cache so the change is picked up
immediately. The write is skipped when the on-disk file is already identical.
https://claude.ai/code/session_01DFVSKgViFaxEjZD2KsTdtt
For MSI installs the installer already writes HKLM Capabilities +
RegisteredApplications, so the "Set as default" dialog works. For
portable .exe builds those registry keys are never created, so the
IApplicationAssociationRegistrationUI dialog silently does nothing.
register_handler() now also writes:
- HKCU\Software\Classes\Applications\OpenCADStudio.exe (Open-with list)
- HKCU\Software\Classes\OpenCADStudio.DWG / .DXF (ProgIDs + icon + open cmd)
- HKCU\Software\Classes\.dwg|.dxf\OpenWithProgids
- HKCU\Software\Open CAD Studio\Capabilities (AssociationToasts shown)
- HKCU\Software\RegisteredApplications (Windows Default Programs)
This makes the "Yes, set as default" button work correctly for portable
builds on all supported Windows versions.
https://claude.ai/code/session_01DFVSKgViFaxEjZD2KsTdtt
Installed builds already register a handler (MSI ProgIDs, the Linux
.desktop MimeType, the macOS Info.plist), but the portable .exe and the
AppImage register nothing, so they never appear in the OS "Open with"
list. Add a best-effort, idempotent runtime registration that runs
silently on a detached thread at startup:
* Windows — writes HKCU\Software\Classes\Applications\OpenCADStudio.exe
(open command + FriendlyAppName + SupportedTypes .dwg/.dxf), which is
what lists the exe in "Open with → Choose another app".
* Linux — writes a user-level .desktop pointing at the running binary
($APPIMAGE when set) and refreshes the desktop database. Skipped when
a system package already provides the desktop entry, so we never
shadow a distro install.
* macOS — no-op; .app bundles auto-register with LaunchServices.
Unlike the default-app prompt this changes no defaults and shows no UI;
it only makes the binary discoverable as a handler.
https://claude.ai/code/session_01DFVSKgViFaxEjZD2KsTdtt
On the first launch that hasn't answered it yet, the app shows a small
dialog offering to become the default handler for .dwg and .dxf files.
The choice is persisted (default_assoc_prompted) so the prompt never
reappears.
The platform plumbing lives in io/file_association.rs:
* Windows — opens the OS's own per-app default-programs dialog via
IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI,
passing the "Open CAD Studio" RegisteredApplications name the MSI
registers. Modern Windows guards the actual default behind a
UserChoice hash, so this is the supported consent path.
* Linux — xdg-mime default against the installed .desktop file, whose
MimeType entries already cover image/vnd.dwg and image/vnd.dxf.
* macOS — LSSetDefaultRoleHandlerForContentType binds the DWG/DXF UTIs
declared in Info.plist to the app bundle id.
The work runs on a dedicated thread (the Windows dialog is modal) with
the result delivered back through a oneshot channel and surfaced in the
command line.
https://claude.ai/code/session_01DFVSKgViFaxEjZD2KsTdtt
