Unable to connect to SpaceNavigator with FreeCAD 0.17 on Fedora 28

[sgrogan]

I just pushed a first version to my Github repository. The Linux build works with Qt5. I will also try to build on Linux with Qt4 and on Mac OSX. I would appreciate, if someone could work on the Windows build.

I can do win builds with QT4 and QT5. I didn't see a link to your repo in this thread.

[tsadowski]

Sorry, its here:

https://github.com/tsadowski/FreeCAD

I tried to change the Windows code as necessary, but you should expect problems.

Cheers, Torsten

[ian.rees]

I kept the option name SPNAV_USE_X11. The option has nothing to do with Wayland directly and the polling driver works under both window systems.

Just to explain why I suggested USE_WAYLAND, in case it's educational (I spend/waste a lot of time dealing with state management like this, and so want to prevent wastage for others):

We have, in a sense, two bits of state that need to be captured here: are we using space navigator or not, and which API. We already have precompiler switches for space navigator, so all that we really need to add is a bit of state for the API choice. One API only works with X11, and the general consensus seems to be that X11 is slowly on the way out the door. And, so at some stage X11 is simply obsolete and we'll strip the X11 code out of FreeCAD. As far as I'm aware, there's no existing switch that says "Use X11" on Linux, as it's just assumed to be that way.

In the X11->Wayland transitional period, it's possible we will need that X11/Wayland switch elsewhere. Further in the future, Wayland (or whatever wins in the nearer term) will be replaced by something else, so at that stage we'll probably need the switch between Wayland and NewThing. So, I think it makes more sense to add a Wayland switch, than an X11 one. At this point, each is just the inverse of the other, so it's an arbitrary decision, but down the track we may need a different switch for Wayland/NewThing - this gives a weak preference to relating the new switch to Wayland.

Another way to put it: assuming we go with SPNAV_USE_X11, if we later add an X11/Wayland switch, we'll then have redundant state. The right thing to do then, would then be to go modify this code again to throw an error if the Wayland switch is set, and SPNAV_USE_X11 is too, because they conflict.

[tsadowski]

We have, in a sense, two bits of state that need to be captured here: are we using space navigator or not, and which API. We already have precompiler switches for space navigator, so all that we really need to add is a bit of state for the API choice.

And we have 3 different platforms. Mac and Win currently use only the 3dConnexion API and on Linux there is the choice between 2 APIs from libspnav. Using space navigator has to different switches depending on the platform: SPNAV_FOUND and FREECAD_USE_3DCONNEXION. I would like to unify these to maybe NDOF_DEVICE_SUPPORT because there might be more in the future. Mac and Win have currently no further API choice.

I don't really care if the switch on Linux is called SPNAV_USE_POLLING or SPNAV_USE_X11, but SPNAV_USE_X11 could simply be dropped when X11 really goes away. I would not like a USE_WAYLAND switch directly connected to the polling interface because Wayland has nothing to do with it and at least in my case FreeCAD runs under XWayland, i.e. X11 but I need to use the polling API.

Cheers,
Torsten

[wmayer]

Using space navigator has to different switches depending on the platform: SPNAV_FOUND and FREECAD_USE_3DCONNEXION.

No, we don't. The SPNAV_FOUND is like every search for a library an internal variable to check if cmake could find the requested library or not. And FREECAD_USE_3DCONNEXION is a cmake option that the package maintainer can switch on or off and so far is only used on Windows and macOS while on Linux SpaceNav support depends on whether the library could be found or not.

[tsadowski]

In that case it should be 3DCONNEXION_FOUND on Mac

But more important right now is the implementation. I did add a new class. Which implementation is used on the different platforms is handled by cmake. The data exchange between GuiNativeEvent and GuiApplicationNativeEventAware is not clean. GuiNativeEvent calls GuiApplicationNativeEventAware::postMotionEvent with a pointer to internal data (motionDataArray). The array is static because it is useful on Mac and it does not hurt. The array could be public and exist in either class or GuiApplicationNativeEventAware gets a copy of the data (std::vector).

Any preferences?

Cheers,
Torsten

[tsadowski]

A short update.

Linux + Qt5 + Spnav Polling interface
- Compiles
- Works under XWayland and X11

Linux + Qt5 + Spnav X11 Interface
- Compiles
- Works under X11 after manually restarting spacenavd

Linux + Qt4 + Spnav both interfaces
- Compiles
- FreeCAD does not start, mismatched libraries

Mac High Sierra + 3Dconnexion
- Compiles
- FreeCAD does not start, Symbol in boost lib not found. Homebrew problems

Windows
- ????

Cheers,
Torsten

[sgrogan]

A short update.

Thanks for bumping this, I had missed your link to your repo.
I don't have a mouse to test but I will post some builds.

[PrzemoF]

COPR builds in progress: https://copr.fedorainfracloud.org/coprs ... ld/821634/
I rebased your branch on top of the current master, so the commit numbers are ahead.
Local build on fedora in progress as well.

[sgrogan]

Local build on fedora in progress as well.

The LinuxSpacenav branch? Did it rebase clean?