A line on the OSX-client-won't-shut-down bug

@Attenwood

You asked for some Mac specific stuff, here you go:

In R24 or R25 I and some others reported that the Mac client would at times not terminate normally and have to be ended with the "Force Quit..." OS X function. (BTW, where do old release bug reports go?) I don't believe that was ever followed up, or you couldn't repeat it - can't remember.

OK, I think I know some if not all of what's going on. Since most Macs have a default one button track pad or mouse, many if not most of us OS X'ers are using add-on pointing devices, in my case a wireless 2-button Logitech mouse that communicates via a USB dongle.

Here's the clue: If I leave that dongle plugged in while SotA is shutting down, it shuts down properly 10 out of 10 times. If I pull the dongle out while SotA is spinning the beach ball during its "Please Wait" time, the program will pull down its UI and then fail to end normally, having to be evicted manually. 6/6 so far. My guess: a blocking call to an API to release a binding to a device that's no longer there.

This may fit with another OS X pointing device issue that I reported even earlier: If the add-on pointing device isn't plugged in when SotA launches, it will then fail to pick up the additional functions that are provided on that device - scroll wheel and second button in this case.

Neither of these is good Mac-ish behavior. I use that wireless mouse regularly with other 3D enabled OS X programs- Inventor Fusion, Sketchup, Repetier, Gephi - and none of them have either the problem of failing to pick up the functions when I plug it in late, or failing to exit normally if I unplug it early.

Methinks there's some non-standard OS X API usage in SotA's binding to pointing devices.

 

Submitting issue for review.