Fix for zoom in/out error #1221
Conversation
On windows 10 the open/save dialogue box has an minor error, and I believe I fixed it. When "Open" is selected from the menu, the title of the dialogue box says "SolveSpace - Save File" and the entered file name is "united". My fix correctly titles the dialoged box, and leaves the address bar blank when a file is being opened because "united" is only needed as a default name when a file being saved. I found that class FileDialogImplWin32 from guiwin.cpp contains two if statements for "isSaveDialog". This is redundant. I removed the first where the title was originally set, but not working. I then set the title in the second if statement and moved the 'if isEmpty'' to this section.
replaced tabs with spaces
…mouse position directly. Simplified MouseScroll in mouse.cpp to point to this function instead of altering zoom directly. Also pointed zoom commpand from keyboard and menu to ZoomToMouse so that it works avoids different behavior.
Created ZoomToMouse function in graphicswin.cpp which referances the …
|
Also want to bring in @vespakoen since he's been in the mouse code and has pending PR #1218 which might conflict? |
|
Just following up on rather this code conflicts with work from @vespakoen |
|
@dustinhartlyn thanks for that update. |
|
@phkahler @dustinhartlyn I am not sure if this is an improvement. It depends whether one considers the old behaviour a bug or a feature. Before this pull request was merged scroll wheel zooming was centered on the mouse pointer and |
@ruevs I still see that behavior on Windows. Have not specifically checked in Linux yet. @dustinhartlyn If I draw a rectangle and zoom while dragging, the zoom with mouse wheel is centered on the point/mouse pointer. If I zoom with +/- it zooms relative to the screen center, but the point being dragged is no longer under the mouse pointer. This seems like the "bug" you set out to fix, or is it different. Either way I don't think this is done yet. On a somewhat related note, I've always wanted the ability to select a point and have rotation be around that point. As it is, rotation when zoomed in usually results if seeing a completely different part of the model. |
@phkahler strange... Ara you sure you have master at fc16cdb ? With that commit I see that zooming in both ways (scroll wheeel and +-) is always "centered" on the mouse pointer - irrespective of whether one is still drawing a rectangle or not and whether LMB is pressed or not. |
|
Hmmm the latest edge build on windows is from this commit c5ea9a44 Yes the snap build is failing:
I re-started the job to see if it will behave differently and it failed again. @ppd do you have an idea what might be happening? |
* minor fix open/save dialogue on windows On windows 10 the open/save dialogue box has an minor error, and I believe I fixed it. When "Open" is selected from the menu, the title of the dialogue box says "SolveSpace - Save File" and the entered file name is "united". My fix correctly titles the dialoged box, and leaves the address bar blank when a file is being opened because "united" is only needed as a default name when a file being saved. I found that class FileDialogImplWin32 from guiwin.cpp contains two if statements for "isSaveDialog". This is redundant. I removed the first where the title was originally set, but not working. I then set the title in the second if statement and moved the 'if isEmpty'' to this section. * Update guiwin.cpp replaced tabs with spaces * Created ZoomToMouse function in graphicswin.cpp which referances the mouse position directly. Simplified MouseScroll in mouse.cpp to point to this function instead of altering zoom directly. Also pointed zoom commpand from keyboard and menu to ZoomToMouse so that it works avoids different behavior. * clean up some comments
* minor fix open/save dialogue on windows On windows 10 the open/save dialogue box has an minor error, and I believe I fixed it. When "Open" is selected from the menu, the title of the dialogue box says "SolveSpace - Save File" and the entered file name is "united". My fix correctly titles the dialoged box, and leaves the address bar blank when a file is being opened because "united" is only needed as a default name when a file being saved. I found that class FileDialogImplWin32 from guiwin.cpp contains two if statements for "isSaveDialog". This is redundant. I removed the first where the title was originally set, but not working. I then set the title in the second if statement and moved the 'if isEmpty'' to this section. * Update guiwin.cpp replaced tabs with spaces * Created ZoomToMouse function in graphicswin.cpp which referances the mouse position directly. Simplified MouseScroll in mouse.cpp to point to this function instead of altering zoom directly. Also pointed zoom commpand from keyboard and menu to ZoomToMouse so that it works avoids different behavior. * clean up some comments
When creating any multi point shape (such as rectangle), if zoom in/out is used from the keyboard or menu after setting the first point of the object, the mouse will be misaligned with the current point.
When I dug into the code I found that there are two different function responsible for zooming in/out. It seems the first was originally created in graphicswin.cpp for the menu option while the second was made in mouse.cpp for the scroll-wheel
Unfortunately having two different functions created to accomplish the same behavior left the opportunity for anomalies and I believe I have fixed the problem by making a single zoom function in graphicswin.cpp. This function takes a single argument which is the zoom multiplier and adjusts the scale centered on the mouse position (same behavior as the zoom function on mouse.cpp). The scroll-wheel event goes to the same function in mouse.cpp, but instead of performing actions directly it points to the shared ZoomToMouse function placed bellow the ZoomToFit function in graphicswin.cpp. The keyboard also points to this function instead of modifying the 'scale' variable directly. Triggering the event from the menu appears to work naturally even though the mouse is positioned over the menu.
In addition to fixing the bug and eliminating a redundant function, I think the ZoomToMouse function offers the opportunity for future development where a call can be easily made to zoom in/out. It could also be modified to be a ZoomToPoint function if needed. The ZoomToMouse function would be changed to forward the mouse position as the point of focus, but I did not see a need to go that far just yet.