WorldWindJava
WorldWindJava copied to clipboard
NASAWorldWind
Fix display of context menu in ContextMenusOnShapes demo.
Note: Filling out this template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainer's discretion.
Description of the Change
Make the AWT screen coordinates available in SelectEvent. This might be needed to display some AWT widget at/near the screen location of a mouse event. The example program "ContextMenusOnShapes" needs the screen coordinate available to display the context menu at the mouse click location.
Why Should This Be In Core?
Bug reported by thwe74; see https://github.com/NASAWorldWind/WorldWindJava/pull/262#issuecomment-1787981190. The example program "ContextMenusOnShapes" wasn't displaying the context menu in the right place on the screen.
Changes for DPI scaling replaced the MouseEvent coordinates with GL surface coordinates. That example program expects to have the AWT screen coordinates available.
Benefits
Makes the AWT screen coordinates available in the SelectEvent
Potential Drawbacks
Applicable Issues
During our tests we found today that there is still a problem with moving icons and annotations on the globe. This can be reproduced in the examples "AnnotationControls", "Annotations" and "ScreenImageDragging". If the icon is display in the map corner and will be dragged with the mouse to some other location the icon jumps to a different place. The position is changing between up/down but left/right seems to be correct. In the center view the position does not change.
https://github.com/NASAWorldWind/WorldWindJava/assets/70937938/1ab83d84-84d3-4e38-9218-5ea61edd302c
@thwe74: please try the changes in commit 5e53f72, and report any additional defects.
The changes to support DPI scaling were extensive, and not all example applications were tested. I'm not surprised to see flaws like this.
Thanks.
@gbburkhardt thanks for the quick fix. I have tested it and this works well. Now I just have one small issue with the rotation of the map if the right mouse button is pressed and mouse moved to the right will rotate the map clockwise instead of counterclockwise. Also if the right mouse button is pressed and move forward/backwards the map perspective changes differently as before. Can this be changed back somewhere?
@thwe74: I've fixed the globe pitch movement using the right mouse button to match what it did before the DPI scaling fix changes. But the left/right mouse movement with the right mouse button down wasn't broken; the code before the DPI scaling fixes rolled the globe CW for left mouse movements, CCW for right mouse movements. All mouse positions were changed to use GL surface coordinates early on during mouse event processing. It makes sense that it wouldn't have changed, since the X coordinate in GL surface coordinates has the same orientation as AWT device coordinates. But Y is flipped. In GL surface coordinates, (0,0) is in the lower left. Both X,Y values are scaled by the current DPI scaling, too.
@gbburkhardt Thanks for the change of the pitch Y. The version we still have is much older and the pitchInput and headingInput inside the BasicViewInputHandler are the same as in the current develop branch but the directions are different. With your modification to flip the Y it works now in the same way for the pitch. For the heading it is a bit confusing now because with the right mouse button you like to move the map from selected point to the position your mouse is going. With the cursor keys (left/right) you are rotating the view camera and map will rotate into the different way.
@gbburkhardt When we have the scaling to 150% on our 4K screens there is a area where rotating the map (heading) with the right mouse button is not working (see screenshot). For 125% scaling the area is only half the size where it does not work and it works for the whole area if 100% scaling is used. Changing the pitch with the right mouse button works in the whole view area. This is not related to your changes because I can see this in all versions we have.
@gbburkhardt Thanks for the change of the pitch Y. The version we still have is much older and the pitchInput and headingInput inside the BasicViewInputHandler are the same as in the current develop branch but the directions are different. With your modification to flip the Y it works now in the same way for the pitch. For the heading it is a bit confusing now because with the right mouse button you like to move the map from selected point to the position your mouse is going. With the cursor keys (left/right) you are rotating the view camera and map will rotate into the different way.
@thwe74: I see shift-right arrow changing the heading in the positive direction, just as moving the right mouse down right does. Note that the compass widget shows the heading and rotates as the heading changes. Right arrow without shift rotates the globe, which is a different operation. I see dragging the globe with the left mouse down moving the mouse right doing the opposite of the right arrow without shift. That sort of makes sense to me.
You can understand why I'm reluctant to make changes to previous behavior. The DPI scaling changes should only the Y direction. But if you want the heading to work differently, it's easy to flip X as well with a private code change, now that the areas BasicViewInputHandler that react to mouse events has been identified. If you think that permanent changes should be made, I suggest you try the forum or submit a bug report.
@thwe74: Good catch! And now I'm embarrassed, having fixed the clamping of the mouse position to the GL viewport for Y but not X in commit d4b6bf4. I'm impressed that you noticed. Thanks.
luctant to make changes to previous behavior. The DPI scaling changes should only the Y direction. But if you want the heading to work differently, it's easy to flip X as well with a private code change, now that the areas BasicViewInputHandler that react to mouse events has been identified. If you think that permanent changes should be made, I suggest you try the forum or submit a bug report.
@gbburkhardt thanks for the response. We will change this in the private repository for now.
@thwe74: Good catch! And now I'm embarrassed, having fixed the clamping of the mouse position to the GL viewport for Y but not X in commit d4b6bf4. I'm impressed that you noticed. Thanks.
@gbburkhardt thanks a lot for the quick bugfix. That helps me a lot that we can keep the WWJ for our development since everyone has now 4k screens. The only missing feature we need is the receive and rendering of vector tiles like mbtiles.