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.
ispyisail
e35cab33f0