4 Commits

Author	SHA1	Message	Date
ispyisail	4381c6caa3	Read the 3D mouse through 3DxWare on macOS when it is installed ... On macOS, 3DxWare installs a driver extension that takes the 3D mouse over. With it installed, HidBackend opens the device but receives nothing, so the mouse did nothing in QElectroTech until 3DxWare was uninstalled (discussion #599, PR #1028). Most Mac owners of a 3D mouse have 3DxWare installed. ConnexionBackend asks 3DxWare for the motion instead, through 3DconnexionClient.framework, as Blender does. SpaceMouseListener tries it first. When 3DxWare is not installed, or is installed but its driver is not running, it falls back to HidBackend, so the device works in both setups. Take-over mode stops 3DxWare's own actions in QET, so the view does not move twice. The library is loaded at run time from where 3DxWare installs it: nothing is linked or bundled, and the build needs no SDK. The few declarations are written here, from Blender's GHOST_NDOFManagerCocoa.mm, because 3Dconnexion's SDK headers may not be redistributed. 3DxWare's axes are y up and z away from the user; they are mapped to QET's raw USB convention by comparing Blender's 3DxWare and spacenavd code paths. The release script signs with the hardened runtime, which refuses a library another team signed. misc/qelectrotech.entitlements adds com.apple.security.cs.disable-library-validation (Blender's notarized build carries the same one), and MacQetDeploy_arm64_cmake.sh now passes it to all four signings of the app, including the re-sign inside the DMG. Tested: tst_spacemouseconnexion runs the backend on every platform against fakeconnexion, a stand-in library that answers from its own thread as 3DxWare does: registration, the axis mapping, buttons, other clients' messages, 3DxWare not installed or not running, deletion with a message in flight. Flipping an axis sign or dropping the client check turns it red. realLibrary() loads the real framework when 3DxWare is installed. Linux Qt 6 build with the 3D mouse enabled: all 18 tests pass. Not tested: on a Mac with a real device. The axis signs and whether buttons arrive as a bitmask with current 3DxWare are unverified. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-25 22:54:07 +12:00
ispyisail	aaeaff55cc	Add a hidapi 3D mouse backend that needs no 3Dconnexion driver ... The 3D mouse only worked on Linux, through spacenavd. This adds a second backend that reads the device directly over USB through hidapi, with no 3Dconnexion driver or SDK: the route to Windows and macOS (discussion #599), and usable on Linux without spacenavd. SpaceMouseHid decodes the raw reports from the device's own report descriptor -- where each axis and button sits, its range, absolute or relative -- so no per-model table is needed, with the classic report 1/2/3 layout as a fallback when the descriptor cannot be read and the 0x1c button list newer devices send. Absolute axes are rescaled to +-500 exactly as spacenavd does, so both backends give QET the same values. HidBackend polls from the main thread (fast while moving, slow when still), emits one sample per poll, and looks for a device every 3 s so plugging one in or back in needs no restart. QET_SPACEMOUSE_BACKEND (auto, spnav, hid) picks the backend; auto keeps libspnav on Linux when it is found and uses hidapi otherwise. hidapi is found through pkg-config as hidapi-hidraw (Linux) or hidapi (MSYS2, Homebrew). A sample arriving in the same millisecond as the previous one now counts for no time instead of a full period, so a burst of queued samples no longer moves the view further than the time it covers. Tested without a device: tst_spacemousehid (descriptor parsing, broken and hostile descriptors, every report form, recordings from real devices once they are added to fixtures/spacemouse), and end to end on Linux through a virtual USB device created with /dev/uhid: the same moves give byte-identical screenshots through the hidapi and libspnav backends, an absolute axis is rescaled as spacenavd does, buttons trigger their bound action, and unplugging and replugging while QET runs (including with a dialog open that a device button opened) reconnects cleanly. Not tested on Windows, macOS or real hardware. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-25 10:55:30 +12:00
ispyisail	e35cab33f0	Extract a SpaceMouseBackend seam ahead of a future Windows/macOS backend ... The user asked for phase 2 (Windows/macOS via 3Dconnexion's proprietary 3DxWare SDK) on top of #635. This sandbox has no 3DxWare SDK, no Windows toolchain, and no macOS toolchain -- nothing to compile, link, or run a single line of platform code against, unlike the Linux/libspnav path, which was built and actually tested here for real. Writing 3DxWare integration code that has never even built would be a materially weaker, unverifiable thing sitting in this PR, so it is not in this commit. What is: the structural seam that makes adding it later a contained, reviewable change instead of a rewrite of code that already works. ## Before SpaceMouseListener did three unrelated things in one class: own the libspnav connection, read spnav events, and apply motion to the active DiagramView. A Windows/macOS backend would have had to either duplicate all of the DiagramView-facing logic (the pan/zoom calls, the Z-to-zoom- factor mapping, the "which view is active" lookup -- all already verified) or bolt onto the same class with a maze of #ifdefs. Either way, touching that file again would put the already-tested Linux path back in scope for review. ## After - SpaceMouseBackend: a tiny interface (isAvailable(), a motion(dx,dy,dz) signal). A backend's only job is owning one platform's connection to the driver/daemon and translating its native event into this one signal. - SpnavBackend: the libspnav code from the previous commit, moved behind that interface with no behaviour change -- still spnav_open() in the constructor, still a QSocketNotifier on spnav_fd(), still silent when no daemon/device is present. - SpaceMouseListener: now backend-agnostic. Owns whichever backend the platform provides, applies its motion to the active DiagramView exactly as before. The DiagramView-facing code (pan/zoom calls, zoomFactorForZAxis) did not need to change at all -- only its input changed from a spnav_event_motion struct to three plain ints. A future 3DxWare backend implements SpaceMouseBackend, is selected in SpaceMouseListener's constructor behind its own QET_SPACEMOUSE_BACKEND_3DXWARE guard (see the comment marking exactly where), and never has to touch SpnavBackend or SpaceMouseListener's DiagramView-facing half. ## CMake: one user option, one define per backend QET_ENABLE_SPACEMOUSE is unchanged as the single option a user sets. Internally, find_spacemouse.cmake now decides *which* backend (if any) that resolves to: on Linux with libspnav found, QET_SPACEMOUSE_BACKEND_SPNAV plus the umbrella QET_SPACEMOUSE_SUPPORT. Turning the option on anywhere else today downgrades cleanly with a warning naming discussion #599, instead of trying (and failing) to find libspnav on a platform that doesn't ship it. Adding 3DxWare later means adding one more branch here, not restructuring this file. ## Verified this is a pure refactor, not just "still compiles" Reconfigured and rebuilt both ways from scratch: - option off: unchanged from before -- no new source files compiled, zero new object code. - option on: both new files compile with zero warnings, binary still links against libspnav.so.0 (confirmed via ldd), and run to completion in this environment (which has no spacenavd) with zero crashes and zero spnav-related output -- identical to before the refactor. - zoomFactorForZAxis re-linked and re-run in isolation: identical output to the pre-refactor commit (z=0 -> exactly 1.0, z=+-350 -> 1.35/0.65), confirming the math moved unchanged rather than being reimplemented.	2026-08-02 21:22:42 +12:00
ispyisail	2e4bb486bb	Add 3D mouse (SpaceMouse/SpacePilot) pan/zoom support via libspnav ... Implements discussion #599's phase 1 (Linux, libspnav): a 3Dconnexion 6-DOF device pans and zooms the active diagram view, via spacenavd. ## Off by default, zero cost when off QET_ENABLE_SPACEMOUSE (cmake/developer_options.cmake) is OFF. Verified in two separate build directories from a clean configure: with it off, the new cmake/find_spacemouse.cmake step runs and does nothing (no library lookup, no definition, no new source files compiled), and qetapp.cpp/.h produce zero new object code -- both are entirely #ifdef'd out. The default build is byte-for-byte the same shape as before this commit. With it on, libspnav is located via its pkg-config file (spnav.pc, shipped by libspnav-dev on Debian/Ubuntu and equivalent packages elsewhere). If the option is on but the library isn't found, this does not hard-fail configure: it downgrades back to off with a warning, so an opt-in feature never blocks a developer who doesn't have the library installed. ## No new navigation logic -- a new input source for the existing one DiagramView::wheelEvent() already turns a physical wheel's delta into horizontalScrollBar()/verticalScrollBar() calls for pan and a zoom(1 + value/1000) call for zoom -- see diagramview.cpp:661-687. SpaceMouseListener calls exactly those same primitives from spnav motion events instead of wheel events. It does not reimplement panning or zooming. ## Safe by construction even when compiled in The overwhelming majority of users of a build with the option on still won't have spacenavd running or a device attached -- that must never surface as an error dialog or a startup warning. SpaceMouseListener:: isAvailable() reflects this: spnav_open() failing is treated as the ordinary case, not an error, and the object then does nothing at all. Verified for real in this environment, which genuinely has no spacenavd running: built with the option on, ran the resulting binary to completion, and confirmed zero crashes and zero spnav-related output of any kind -- the silence is the point. Motion is read via a QSocketNotifier on spnav_fd() (event-driven, no polling loop, no idle cost) and applied to whichever DiagramView is currently active, found via qApp->activeWindow() -> QETDiagramEditor -> currentProjectView() -> currentDiagram(): a 6-DOF device is one ambient input source for the whole application, not something tied to a particular window, so there is exactly one listener, owned by QETApp. ## What could not be verified without hardware The Z-axis-to-zoom-factor mapping (SpaceMouseListener::zoomFactorForZAxis) is a pure function specifically so it could be tested without a live device: confirmed a centered device (z=0) yields exactly 1.0 (an exact no-op, not an epsilon-off value that could trip DiagramView::zoom()'s >=1 branch), and that push/pull produce symmetric zoom-in/out factors. What genuinely cannot be checked in this environment: which physical axis is "left/right" vs "up/down" vs "push/forward", their sign, and whether the ZOOM_DIVISOR/PAN_SCALE constants feel right on real hardware. Both are named constants specifically so recalibrating them is a one-line change once someone with a device tries it -- flagged plainly in the PR rather than presented as verified. ## Not in this commit Windows/macOS (proprietary 3DxWare SDK, materially bigger lift) and device button mapping are both explicitly out of scope for this phase per the discussion.	2026-08-02 21:04:57 +12:00