Step-level if: conditions cannot read the secrets context, which made
GitHub reject the workflow file outright (startup failure, zero jobs).
The signing waterfall now keys off job-level env booleans mirrored from
the credential secrets - a pattern actionlint accepts.
Forks do not inherit repository secrets, and the previous hardwired
Azure Trusted Signing steps failed the Windows job outright on a fork.
Each signing step is now gated on its credentials being present and the
pipeline falls through: Azure Trusted Signing (upstream setup, unchanged
when the secrets exist) -> PFX certificate from WINDOWS_PFX_BASE64 /
WINDOWS_PFX_PASSWORD via signtool with RFC-3161 timestamping -> unsigned
with a note in the job summary. The build and installer assembly always
complete.
Builds from main reported only the release version (2026.36) even when
HEAD was hundreds of commits past the tag. build.rs now also emits
OCS_TAG_DISTANCE, OCS_COMMIT_DATE, OCS_BUILD_METADATA and
OCS_FULL_VERSION: a clean checkout of the release tag stays "2026.36",
anything else becomes "2026.36+194.gef189d77", with ".dirty" appended
for uncommitted changes and only the hash when no tag can be counted
from (shallow clone, tarball). OCS_APP_VERSION is unchanged so the
update check, donation gate, User-Agents and window title keep working.
The About dialog gains Build / Commit date / Profile cards, Copy Info,
the REPORT issue template and recovery reports carry the full version,
and `-V`/`--version` print it instead of Cargo's 2026.36.0. Release
workflows check out full history so release binaries see the tag.
Also fixes the build being marked dirty when there is no repository:
diff-index exits 128 there, not 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Reuse the application library from the binary entry point instead of compiling the module tree twice. Keep desktop-only transports and caches out of web builds, remove unused test code, and check executable targets in CI.
Snapcraft strips the sole usr directory from tar sources, so extract the artifact directly and retain its desktop-file path.\n\nAdd a snap-only manual target to avoid rebuilding other platforms while validating packaging fixes.
Requested in review: this repo's working language is English, so the
comments carried over from the OpenAEC sibling repos have been
translated. No functional changes -- only comments and log/error strings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The feature existed for one reason: truck's mesh and boolean crates reach
`vtkio → xz2 → lzma-sys`, a C library that cannot cross-compile to wasm32. So
the web build dropped it, and with it the Model tab, solid tessellation and
ACIS import — all of which quietly did nothing in the browser.
cadkernel is pure Rust and has no C dependency, so none of that holds any
more. The feature gated exactly two things by the end, `acis_export` and the
save-path sync that calls it, and both are as portable as everything around
them. Removing it means the web build makes primitives, runs booleans, draws
ACIS solids read from a file, and writes them back out as exact geometry — the
same as the desktop build.
Verified against all three: native, `--no-default-features`, and an actual
`wasm32-unknown-unknown` check rather than an assumption about one.
The docs claimed otherwise in four places and are corrected. `tessellation.md`
in particular was organised around whether an entity "goes through truck",
which is no longer a question anything can be asked — the three paths are now
a kernel B-rep mesh, a curve sampled through `entities::curve`, or geometry
emitted directly, and the per-entity table is updated to match.
`index.html` no longer passes `data-cargo-no-default-features`; there are no
features left to turn off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The job deleted its own run once the comment was posted, so a failure to
post left nothing behind to look at. Keep the run, and drop the
`actions: write` permission it needed only in order to delete itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Repackages the released Linux AppImage (--appimage-extract) instead of
rebuilding from source, triggered on completion of the "Release" workflow.
Publishing to the Snap Store only happens once SNAPCRAFT_STORE_CREDENTIALS
is set as a repo secret.
Different from the other OpenAEC snaps in one important way: OCS uses
winit + wgpu (Vulkan/GL), not GTK/WebKit, so this uses explicit
opengl/wayland/x11 plugs and staged Mesa/X11/Wayland runtime libraries
instead of the `gnome` extension.
Higher confidence in the packaging mechanics (build succeeds, produces a
valid .snap) than in the actual runtime GPU/windowing behavior under
strict confinement, which needs real hands-on testing on a Linux desktop
before publishing to stable -- see the PR description.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A plain `cargo build --release` at the workspace root builds only the app
package and its dependencies, so it never emitted the artifacts the
packaging steps consume:
* libdwg_thumbnailer.a — the staticlib crate-type is produced only when
dwg-thumbnailer is built as a target (as a dependency cargo makes just
the rlib); the macOS QuickLook .appex links this static lib.
* dwg_thumbnailer_win.dll — dwg-thumbnailer-win is a workspace member,
not an app dependency, so the DLL the WiX MSI references was missing.
Build each helper crate explicitly on its platform, and link the extra
system libraries (Security/SystemConfiguration/iconv) the Rust staticlib
pulls in against the QuickLook extension.
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 browser can't call the Patreon API directly (CORS, and the token
would be exposed in the bundle), so the web build fetches a
pre-generated supporters.json served on the same origin. The Pages
workflow generates it server-side with the token (CI secret) after the
trunk build. Native keeps its live API fetch.
serde_json moves to the shared dependencies so the wasm build can parse
the list.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a right-hand rail on the Start page listing active paying patrons
(name + pledge amount, highest first) with a "Support on Patreon" button.
The list is fetched once at boot from the Patreon API in the background;
free followers, $0 tiers, declined and former patrons are excluded.
The creator access token is read at build time from OCS_PATREON_TOKEN
(option_env!), so it never lives in source or git — the release workflow
passes it from a repo secret, and build.rs re-bakes when it changes.
Without a token the rail just shows the support button.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add .github/workflows/pages.yml: on every published release (and manual
dispatch) it builds the web bundle with trunk
(`--public-url /OpenCADStudio/`, no-default-features so no solid3d/C
deps), adds .nojekyll, and publishes dist/ to GitHub Pages. No COOP/COEP
needed since wasm runs single-threaded.
Enable via repo Settings → Pages → Source: GitHub Actions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Windows installer:
- Optional Desktop shortcut feature (default on, deselectable) via a switch to
the WixUI_FeatureTree UI.
- Refresh the shell after install (ie4uinit -show) so .dwg/.dxf icons and
associations appear without a reboot.
- Tidy the Add/Remove Programs entry: ARPNOREPAIR plus contact/update/comments
metadata (Modify stays enabled for the feature tree).
Release workflow:
- Publish SHA256 sidecars for the AppImage, portable .exe, MSI and .dmg.
Linux:
- Ship an AppStream metainfo.xml for software-centre integration.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Windows executable carried no icon, so Explorer, the taskbar, the
Start-menu tile and file-association entries showed a generic icon. Embed
AppIcon.ico via winresource in build.rs, and generate the .ico from the logo
before the build (it was produced after the build, too late to embed). Local
and non-Windows builds skip the step when the .ico is absent.
Fixes#107.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hakan Seven