macOS native bridge port
Ported the Windows-only native palette bridge (native/VwxBridgePalette.cpp + ModuleMain.cpp) to macOS from scratch, against the Vectorworks Mac SDK. Confirmed working end-to-end against a live Vectorworks 2026 document — reads and writes both tested via MCP tool calls, including writes while Vectorworks was backgrounded/unfocused.
Branch (on my fork, not touching your repo): https://github.com/chandz102/vwx-mcp/tree/macos-native-port — see native-macos/PORT_NOTES.md for the full write-up.
A few things that came out of the port that might be useful even outside a merge:
- A real crash cause:
GetStandardURL()'s resource lookup is keyed on DefaultPluginVWRIdentifier()'s string, which must match the built .vwr folder name exactly, or the SDK dereferences an uninitialized file identifier (EXC_BAD_ACCESS on palette open).
.vwstrings files need UTF-16LE with BOM on this SDK build, not UTF-8 — worth knowing if you ever touch resource files on the Mac side.- The mutation-trigger design simplifies nicely on macOS: instead of the keystroke-injection dance (
keybd_event/PostMessage with separate foreground/background paths), gSDK->DoMenuName("VWX Bridge Start", 0) triggers the same menu command directly through VW's own dispatcher. It's an in-process call rather than a synthetic OS event, so it works regardless of VW's focus state — meaning the whole foreground/background split isn't needed on macOS at all.
- One found-and-fixed bug worth flagging regardless of platform:
CountJobs()'s opendir() call included a glob pattern (.../ipc/jobs/*.json) — opendir() doesn't glob-expand, so it silently returned 0 forever. Not sure if this affects the Windows path too (it uses FindFirstFileW with the pattern, which is correct for that API) but wanted to flag it in case a similar helper exists elsewhere.
Still stubbed on macOS: auto-dismiss-error-dialogs (needs the Accessibility API + a permission grant, deferred as non-critical — failure mode is just a timeout, not a crash).
Happy to open a PR against native-macos/ as a new directory (doesn't touch the existing Windows build at all) if that'd be useful, or just leave this as a reference for whenever you get to Mac support.
macOS native bridge port
Ported the Windows-only native palette bridge (
native/VwxBridgePalette.cpp+ModuleMain.cpp) to macOS from scratch, against the Vectorworks Mac SDK. Confirmed working end-to-end against a live Vectorworks 2026 document — reads and writes both tested via MCP tool calls, including writes while Vectorworks was backgrounded/unfocused.Branch (on my fork, not touching your repo): https://github.com/chandz102/vwx-mcp/tree/macos-native-port — see
native-macos/PORT_NOTES.mdfor the full write-up.A few things that came out of the port that might be useful even outside a merge:
GetStandardURL()'s resource lookup is keyed onDefaultPluginVWRIdentifier()'s string, which must match the built.vwrfolder name exactly, or the SDK dereferences an uninitialized file identifier (EXC_BAD_ACCESSon palette open)..vwstringsfiles need UTF-16LE with BOM on this SDK build, not UTF-8 — worth knowing if you ever touch resource files on the Mac side.keybd_event/PostMessagewith separate foreground/background paths),gSDK->DoMenuName("VWX Bridge Start", 0)triggers the same menu command directly through VW's own dispatcher. It's an in-process call rather than a synthetic OS event, so it works regardless of VW's focus state — meaning the whole foreground/background split isn't needed on macOS at all.CountJobs()'sopendir()call included a glob pattern (.../ipc/jobs/*.json) —opendir()doesn't glob-expand, so it silently returned 0 forever. Not sure if this affects the Windows path too (it usesFindFirstFileWwith the pattern, which is correct for that API) but wanted to flag it in case a similar helper exists elsewhere.Still stubbed on macOS: auto-dismiss-error-dialogs (needs the Accessibility API + a permission grant, deferred as non-critical — failure mode is just a timeout, not a crash).
Happy to open a PR against
native-macos/as a new directory (doesn't touch the existing Windows build at all) if that'd be useful, or just leave this as a reference for whenever you get to Mac support.