Skip to content

v0.1.0

Choose a tag to compare

@gsdali gsdali released this 19 Aug 12:57
· 18 commits to main since this release
bbeadbe

First release of OCCTSwiftInteraction, the merge of OCCTSwiftTools, OCCTSwiftAIS and OCCTSwiftCADKit into one package vending three targets (ecosystem#42).

Migrating is a manifest change and nothing else

Your import lines do not change. The module names are unchanged, because each is still its own SwiftPM target. Replace up to three dependency entries with one and update the package: label on each product:

// before
occtDep("OCCTSwiftTools",  from: "1.6.4"),
occtDep("OCCTSwiftAIS",    from: "1.3.2"),
occtDep("OCCTSwiftCADKit", from: "1.1.2"),
.product(name: "OCCTSwiftTools", package: "OCCTSwiftTools"),

// after
occtDep("OCCTSwiftInteraction", from: "0.1.0"),
.product(name: "OCCTSwiftTools", package: "OCCTSwiftInteraction"),

Full detail, including which of the eight dependent repos uses what: docs/MIGRATION.md.

Depending on this package does not pull SwiftUI into a headless build. SwiftPM compiles only the targets reachable from the products you name, and OCCTSwiftTools imports no UI framework. That property is what made merging these three safe, and it is enforced by target dependencies rather than convention.

What is in it

Everything the three repos carried at their final versions, plus four pieces of work done since:

  • OCCTSwift v3.0.0 across all three targets (ecosystem#39). The six bounding-box accessors that became Optional are unwrapped at every call site, guarding into real failure paths rather than defaulting to a zero-size box at the world origin.
  • Face identity is settled as OCCT's IsSame semantics (#1). A face shared between two shells is one identity, faces() is the enumeration behind FaceIdentityTable, and a caller needing to know which use of a shared face was picked reads orientation off the returned shape. This also fixed five assertions that had been failing since 2026-08-10, when OCCTSwift 2.0.0 arrived transitively and nothing in CI compiled a test target to notice.
  • One pick resolver (#2). OCCTSwiftTools.SubShapePickResolver is now the only place a render-path ordinal becomes a SubShapeRef, and SubShapeRef, SubShape and InteractiveObject moved down to OCCTSwiftTools accordingly. Clip-plane awareness, geometry enrichment and the whole-body fallback deliberately stayed in their own layers.
  • One selection store (#3). CADViewportService used to keep a selection alongside the InteractiveContext it already owned; it now drives that context and projects it.

343 tests across 30 suites, all passing, with swift build, swift build --build-tests, swift-format lint --strict and swiftlint lint --strict clean.

Breaking changes for consumers of the old CADKit

Seven items, listed in full in docs/CHANGELOG-OCCTSwiftCADKit.md. The ones most likely to reach you:

  • SelectionSummary is renamed SelectionMeasurements, deprecated alias retained. It never collided with OCCTSwiftUX's same-named type, which is a different thing entirely.
  • selectionModes is InteractiveContext.selectionMode rather than a copy, initialised to [.face], overriding the context's [.body] default. The two selections are no longer independent.
  • selection is ordered by (body id, kind, ordinal) rather than by selection order, since the store is a Set.
  • Assigning selectionModes now clears the selection.

PadCAM's usage keeps working unchanged; its one exposure is that mode default.

Why 0.x

1.0.0 is reserved for when the picking consolidation finishes. Two phases remain, both in other repos: OCCTSwiftUX#29 and OCCTMCP#182. This tag exists so those can start.

Known and unverified: the visionOS/tvOS platform claim is inherited from the Tools and AIS manifests and is untested for the CADKit target, which previously declared only iOS and macOS. Confirm or narrow before 1.0.0.

The three old repositories are archived rather than deleted, so their tags stay resolvable and an unmigrated consumer keeps building until it chooses to move.