Thanks for the investigation!

@xythobuz Can you please take a look at this?

Of course. I'm unfortunately not able to really test this, as my main work machine is currently unusable thanks to a broken SSD...

Still, I did some investigating and may have found some things out:

First of all, I should mention, I do not own a proper 3DConnexion device and never tested it with their driver and their hardware. I've only been using my own spacenav fork with my self-written reimplementation of the 3DConnexion driver. So the API is the same, but some specifics might be different.

In this case, it really looks to all be related to the CFBundleIdentifier and the program name passed to the 3DConnexion driver.

Here is the code initializing the driver API. connexionSignature, which is set to "SoSp" here, is seemingly used to identify the Window / Application that should receive the input, according to this forum thread.

Edit: sorry, I meant connexionName, connexionSignature is limited to 4 chars!

It should in theory be possible to pass kConnexionClientWildcard there ('****'), instead of "SoSp", to match all applications and always receive input. But I don't think that's the best way. The other possibly related flag is kConnexionClientModeTakeOver, which could be replaced by kConnexionClientModePlugin, but I'm also not sure if that's the proper route.

In my opinion, the proper solution could be similar to:

• Set the CFBundleIdentifier in here to something like "com.solvespace.solvespace" (see the docs)

• Set the connexionName to the same identifier.

I think that should hopefully solve the problem 😃

Also, I may be totally wrong, and this could also be a problem with the official 3DConnexion driver, according to this discussion on their support forums.

As I said, I don't own any 3DConnexion devices and never used their driver, so I can't verify this unfortunately.

@xythobuz
Thank you for your input! I have done some research based your input, and was able to fix the problem.

1. I added the CFBundleIdentifier parameter, "com.solvespace.solvespace" to the cmake/MacOSXBundleInfo.plist file.
2. The connexionName variable needed to be defined differently on Line 1271 in the file src/platform/cocoamain.mm
   I explicitly defined the connexionName string instead of using a pointer.
   Before:
   static UInt8 *connexionName = (UInt8 *)'SolveSpace';
   After:
   static UInt8 connexionName[] = {10,'S','o','l','v','e','S','p','a','c','e'};

This first fix allows solvespace to be added to the 3Dconnexion configuration for custom button assignments as stated above.
The second fix allows the name SolveSpace to be sent correctly to the driver. To be honest, I don't know enough about variables types to figure out why the original pointer type variable for connexionName is preventing it from working, but this solution works.

In other issues of compiling with 10.12, I get some warnings.
Starting from macOS 10.12, the following is deprecated: NSShiftKeyMask, NSCommandKeyMask, NSTitledWindowMask, NSClosableWindowMask, NSMiniaturizableWindowMask, NSResizableWindowMask, NSUtilityWindowMask, NSWarningAlertStyle, NSInformationalAlertStyle, NSKeyDownMask, NSFlagsChangedMask, NSKeyUpMask.

I'll see if I can find a fix for this too.

Just an update. This above fix did allow the use of the 3Dmouse in solvespace, but it still reacts to the 3dmouse input if another application like the "3Dx Axis" demo or "FreeCAD" is opened and is the foremost window.

I've applied the fix in master. Thanks everyone!

I've applied the fix in master. Thanks everyone!

added this to the 3.0 milestone

Think, this bugfix info should be added into changelog:

• https://github.com/solvespace/solvespace/blob/master/CHANGELOG.md#L125

125c125
<   * 3Dconnexion SpaceMouse should now work (on Windows).
---
>   * 3Dconnexion SpaceMouse should now work (on Windows and OS X).

#598