Adds a preference for cusor reset behavior

[NathanC]

This adds a preference to cause the cursor to stay in the center (where the navigation crosshair is) after exiting navigation, initally based on issue https://github.com/SpectralVectors/RightMouseNavigation/issues/14

My initial stab at just commenting out the cursor resetting had a bug-- the cursor would stay in the center even when a menu was opened, causing the menu to be far away from the cursor.

To fix that, I added in a check that only resets the cursor if the preference is enabled AND navigation wasn't cancelled, leading to a menu opening. Now, the cursor is properly positioned on the menu if a menu is opened.

@SpectralVectors I strongly believe that not resetting the cursor should be the default behavior, which is how I've set it up in the PR. In the issue, you said users requested the resetting

because users found it jarring to have their cursor snapped to the center of the screen after each move operation.

My gut is saying that they found the offset between menu and mouse jarring, not that the majority of them disliked the cursor staying in the center after actual navigation.

As a new user of this, coming from Unity (and using scroll wheel click to get somewhat similar behavior of invoking navigation in blender before I found this plugin), the resetting of the cursor was very jarring. I'd be in navigation for a few seconds, and then when I released my cursor would jump to what felt like a random screen location (as the context of me having my mouse there before was no longer relevant). It was jarring enough that it almost stopped me from using the plugin.

That being said, it's your project, so if you feel really strongly about it, I can of course change the default behavior, though I'd like to have a discussion first if possible.

Anyhow, this is my first blender plugin change, so if I did anything wrong please let me know! Thanks for making this tool, it's really awesome.

[SpectralVectors]

I thought about this for a while, and I do feel strongly about the default remaining the same. I was one of the users that found the cursor snap buggy, even if it's Blender's default. The addon was originally called UnrealRightClick, to emulate right mouse behavior in Unreal Engine, which allowed your cursor to remain on the item you were previously on before you started navigation. I find, especially in Edit Mode, selecting faces or vertices, it really bothers me to no longer be hovering over the vertex that I want to be working on. If you don't mind switching the default back I'll test and merge the changes. Thanks for taking the time to add to the addon, it is definitely an improvement that many users will appreciate, and it takes it one step closer to Mac/Linux compatibility as a little side-bonus.

[NathanC]

@SpectralVectors Okay, I appreciate you giving it some some thought, and I've changed the default value to the current behavior.

I'm enjoying the add-on (though trying to teach myself the default blender navigation as well!), but the screen shifting/jumping a bit when doing the menu click is sub-optimal. I've been trying to think of some way around it, but it seems like a hard problem (constrained by the way navigation behaves in blender, not your fault at all). I think I might rebind menu to shift + RMB, would you mind if I added a setting for changing that behavior?

[SpectralVectors]

Great work, sorry I didn't get a chance to test it for a few days. I'm less sure about the Shift+RMB shortcut, but if you want to handle it the same way as the previous: leave the default behavior the same, but add a preference for users who want it, then I could merge those changes, too.

As you noted, I'm not really doing anything to change the navigation behavior, more just remapping how it and context menus are called. If you want to try messing around with the nav behavior, you can try playing with the 'Walk/Fly Modal Map' or try tweaking some of the other navigation features: - use Fly instead of Walk, Gravity, Jumping etc.

I've never pushed the limits of the nav system to see what is possible with Python and what would require changes to the Blender source, but there might be more that you can do than what I've exposed.

Thanks!