@WickedSmoke please consider this #1221 (comment) in context of your pull request. I have not played with yours yest but they are definitely related.

I'm not sure what to take away from that specific comment, but after reading the issue I have checked the zoom behavior during mouse edit operations. A centered zoom does cause dragged points to move away from the pointer, so I've pushed a new commit that suppresses the option during editing as a temporary solution.

Note that even when zoom to pointer is applied, points can still drift away from the pointer with lots of moving while zooming (perhaps due to the relative tracking from the initial button press position?). This should probably be reported as a bug.

I'm not sure adding options is the right fix, but I'm also not sure what the problem is.

Are you zooming with the keyboard? I usually zoom with the mouse wheel and it keeps whatever is under the mouse pointer as the center of zoom. Just now I tried dragging (right mouse) and zooming while the button is down and got a few glitches.

What sequence of inputs are you doing that is causing problems? It might be a bug, or it might need an option ;-)

I use the mouse to rotate and zoom, but I don't want the position of the pointer to change what the camera is looking at when zooming. After each view rotation the pointer position will have moved to some essentially random location on screen. A subsequent zoom will then move the model towards/away from that random location and also change the offset. Each round of this tends to move the point of rotation farther and farther from the model so that rotation quickly puts the model out of view. At this point the view needs to manually be reset to continue working.

This option keeps zooming adjustments independent of offset (which has it's own control via the RMB panning). Without it I feel like I'm fighting the program just to keep my stuff in view.

I used to zoom with the keyboard (+ and -) or the mouse wheel depending on what I wanted - viewport centered zoom or mouse cursor centered zoom. Unfortunately #1221 broke this - and it still got merged. In my opinion that was a step in the wrong direction.

My inclination would be to revert #1221 instead of introducing more UI - as you are doing in this P.R. Try reverting it and using both keyboard and mouse wheel for zooming - I'm curious what you would think of that way of working.

I agree that both methods of zooming need to be supported. I don't think the different input methods should be mapped to different zooms however. So far I've never used the keyboard controls for this, so the mouse needs to operate to my preferences.

There could be a "Default Zoom Mode" option (To Pointer / Centered) which both key and mouse input would use. Then, a key modifier could be added to enable the alternate zoom method on-demand.

If mapping inputs to mode is desired then two options would be needed.

• Mouse Zoom Mode: [To Pointer / Centered ]
• Key Zoom Mode: [To Pointer / Centered ]

I like the CTRL key inverting the configured zoom behaviour.
Would it be appropriate to change the text of the option to:
zoom keeping view centered (hold CTRL while zooming to invert behaviour)
Or something similar?

I'm not on a computer the next few days (and am thus too lazy ot check), but if the + and - zooming is implemented through the standard keyboard accelerators it may be a bit harder to add the CTRL modifier for them.

@ruevs you are correct about the CTRL modifer. I left a note in commit 099042e which was pushed a couple days ago.

That description is a bit verbose. Really tool tips are needed on the checkbox items for that sort of thing.

The whole method of defining the GUI through Print statements is a bit funky. I was looking at adding Combo boxes (similar to the Buttons), but I'm not sure that can work interleaved with the Printed stuff.

That description is a bit verbose.

You are right. And there are many hard to discover features already.

We'll update the documentation - let people read :-)

As for combo boxes and "UI through Printf" - it is weird - when I started tinkering with SilveSpace on 2014 I was also rather... surprised by it. But in a very "twisted" way I like it a lot - it removes UI as a "thing" to "do" in the software. This may be part of the reason SolveSpace is so "immediate" and "pure" - every time Jonathan, Whitequark, whoever wanted to do some "fancy" UI they "bumped" into the "Printf UI 'framework' " and thought of a better way to do it "without classic UI". This is one of a the best aspects of the SolveSpace UI - there is no UI for the sake of UI - it is only there in the absolutely minimal form needed to " do the job".

@WickedSmoke I think there is a desire to have rotation about a point if one is selected. Would it be better to have that AND have zoom work on a selected point be better? These would maintain current behavior if nothing is selected of course.