Add macOS Cocoa drag&drop handler for drop-zone highlight

[meshinspector-agent]

Context

On macOS the drop-zone highlight shown while dragging a file over the window never appears, although the file drop itself works. The highlight is driven by the viewer's dragEntranceSignal / dragOverSignal, emitted by native per-platform handlers — but getDragDropHandler() returned null on macOS, so no drag enter/over/leave events ever reached the UI.

Changes

• Add MRDragDropCocoaHandler (.h pure-C++ PIMPL + .mm implementation), modeled on MRTouchpadCocoaHandler: it injects NSDraggingDestination methods into the GLFW content view via the Objective-C runtime.
  • draggingEntered: chains to GLFW's implementation and emits dragEntranceSignal(true).
  • draggingUpdated: emits dragOverSignal(x, y), converting the Cocoa location to the top-left-origin, framebuffer-pixel convention used by the Win32/Wasm handlers.
  • draggingExited: emits dragEntranceSignal(false).
  • performDragOperation: is left untouched, so GLFW keeps delivering the actual drop via dragDropSignal (which also clears the highlight).
• Wire getDragDropHandler() to return the Cocoa handler under __APPLE__.

No CMake / .vcxproj changes: *.mm is auto-globbed on Apple and AppKit is already linked; the handler never enters the Windows build.

Verification

• Builds: the non-Apple factory path (MRDragDropHandler.cpp) compiles cleanly on the Linux CI image (g++-12 -std=c++20 -fsyntax-only). The Objective-C++ .mm is __APPLE__-only, so the macOS build is its first real compile.
• Not exercisable here: the highlight is a macOS-only UI behavior; it cannot be driven on the Linux runner (no AppKit; the .mm is __APPLE__-guarded), so there is no MCP/automated path to it on this CI.
• Manual macOS check (pre-merge): with upload-binaries, CI publishes the macOS build — download it and confirm that dragging a file over the window highlights the scene-list and viewport drop zones on enter/move and clears them on leave/drop, and that dropping still loads the file.

CI

upload-binaries — to publish the macOS artifact for the manual drag&drop check above.

[Grantim]

please fix builds

[meshinspector-agent]

Addressing "please fix builds" — the whole red cascade traced back to a single failing check, config / prepare-config:

• Root cause — scripts/check_vcxproj.py requires every .h under source/ to be registered in the matching .vcxproj. The new macOS-only header MRDragDropCocoaHandler.h is deliberately not part of the Windows build, so the check reported it as a missing ClInclude and prepare-config exited 1. Fixed in f251bb9 by adding it to IGNORED_FILENAMES, right next to the sibling Cocoa PIMPL headers (MRFileDialogCocoa.h, MRTouchpadCocoaHandler.h) — the existing convention for macOS-only headers excluded from the VS project. (.mm files aren't checked, so no other entry was needed.)

• Why everything else was red — all downstream of that one failure:

  • update-dev-documentation — the build/versioning jobs gate on prepare-config, so they were skipped; with no PythonStubs/CBindings artifacts produced, the doc job failed.
  • test-distribution / macos-test — with versioning skipped, release_tag was empty, so it downloaded the stale latest release (3.1.2.192) instead of a fresh PR package. That old binary links libjsoncpp.26.dylib, which current Homebrew jsoncpp 1.9.7 no longer ships → dyld abort. Unrelated to this PR's source; master's macos-test is green because it tests a freshly-built package.

• State now — config / prepare-config is ✅ on f251bb9 and the build/test jobs are no longer skipped (queued/running), so the doc and macos-test cascades clear once the fresh package builds.

Verified locally (MeshInspector build image): reproduced the check failing on the old head and passing after the fix; compiled the PR's only changed translation unit MRDragDropHandler.cpp cleanly with the real CI CMake config (on Linux it's a no-op — the Cocoa include is __APPLE__-guarded).

Not verifiable here: the Objective-C++ MRDragDropCocoaHandler.mm and the drop-zone highlight are macOS/AppKit-only — no AppKit toolchain on the Linux runner and no MCP-drivable surface — so the now-unblocked macos-build-test job is their first real compile, and the manual drag&drop check from the PR description still applies.

[Grantim]

Issue: the drop-zone highlight sometimes stays stuck because the "leave" (dragEntranceSignal(false)) never arrives. The handler clears the highlight only from draggingExited:, but AppKit does not send draggingExited: in several terminal cases:

• Accepted drop → AppKit sends performDragOperation:, not draggingExited:. For file drops that's fine (GLFW's performDragOperation: fires the drop callback → dragDrop_() clears the flag). But GLFW returns YES without calling the drop callback when the pasteboard has no file URLs — and GLFW registers NSPasteboardTypeURL as well, so a non-file URL drag (a Safari tab / link / bookmark) enters → highlight on, then drops → no drop callback and no exit → stuck.
• Cancelled / interrupted sessions: Esc while inside the window; Cmd-Tab / Mission Control / switching Space or display / source app quitting mid-drag; or a fast flick out coinciding with focus loss. None of these guarantee draggingExited:.

draggingExited: is documented only for "the image exits the view's bounds", so relying on it as the sole clear path is the root cause. (Win32 avoids this because OLE's IDropTarget guarantees exactly one of Drop/DragLeave after DragEnter; Cocoa's only outcome-independent terminal callback is draggingEnded:.)

Fix (scoped to MRDragDropCocoaHandler.mm): also inject draggingEnded: — the callback AppKit sends to the destination at the end of every session (drop, exit, or cancel; macOS 10.7+) — and emit dragEntranceSignal(false) from it, exactly like onDraggingExited does (registry guard → emplaceEvent("Drag leave", … dragEntranceSignal(false)) → postEmptyEvent()).

• Declare onDraggingEnded alongside the other static callbacks in Impl.
• Install it with the same class_addMethod / class_replaceMethod pattern as draggingExited:; selector @selector(draggingEnded:), type encoding "v@:@".
• Keep draggingExited: as-is (still correct for a genuine bounds-exit). The double-clear is idempotent — dragging_ = false twice, and after a real file drop dragDrop_ already cleared it — so firing on draggingEnded: after a normal drop is harmless. No need to touch the enter path.

Verification — this can't be exercised on CI (no macOS/AppKit on the runners, and the .mm is __APPLE__-only), so no automated check is expected here. As a manual pre-merge pass on the upload-binaries macOS build, the highlight should clear in each of:

1. drag a file in, then press Esc (cancel while still inside the window);
2. drag a non-file item in (e.g. a Safari tab / link) and release it on the window;
3. drag a file in, then trigger Mission Control / switch Space mid-drag;
4. regression: a normal file drop still loads the file and clears the highlight.

[meshinspector-agent]

Addressing the review — agreed, relying on draggingExited: as the sole clear path is the bug, and draggingEnded: is the right terminal hook (it's the only outcome-independent callback AppKit guarantees after a session starts). Implemented in 53e7e84, scoped to MRDragDropCocoaHandler.mm, enter/over/exit paths untouched:

• "also inject draggingEnded:" — declared onDraggingEnded alongside the other static callbacks; installed it with the same class_addMethod → class_replaceMethod fallback used for draggingExited: (selector @selector(draggingEnded:), type encoding "v@:@").
• "emit dragEntranceSignal(false) exactly like onDraggingExited" — onDraggingEnded mirrors it: registry guard → emplaceEvent("Drag leave", … dragEntranceSignal(false)) → postEmptyEvent(). As you noted, the double-clear is idempotent (with draggingExited: on a genuine bounds-exit, and with the post-drop clear after a real file drop), so a normal drop is unaffected.
• Kept draggingExited: and the enter path as-is; updated the destructor comment to note draggingEnded: also stays installed.

Verification — consistent with your note, there's no automated check possible here: source/MRViewer/CMakeLists.txt globs *.mm only under IF(APPLE), so the file isn't part of the Linux build and there's no AppKit/Objective-C++ toolchain on the runner to even syntax-check it. So no build/MCP gate ran for this change. First real compile is the macOS upload-binaries artifact; the four manual scenarios you listed remain the pre-merge pass:

1. file in → Esc (cancel while inside the window);
2. non-file item (Safari tab/link) released on the window;
3. file in → Mission Control / Space switch mid-drag;
4. regression: a normal file drop still loads the file and clears the highlight.