mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-28 04:54:13 +02:00
ispyisail
e35cab33f0
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.