Fix display of context menu in ContextMenusOnShapes demo. #274
Conversation
… of AWT screen coordinate when creating SelectEvent.
|
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". Mouse_Image_Move.mp4 |
|
@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? |
…edition has used AWT size of canvas, and mouse positions from MouseEvents are converted to GL surface coordinates early on.
…I scaling changes. Moving the mouse down should increase the pitch, so it appears that the top of the globe is rotated away from the eye.
|
@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. |
… by FlyViewInputHandler, and per frame mouse/key events.
|
@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. |
@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. |
…edition has used AWT size of canvas, and mouse positions from MouseEvents are converted to GL surface coordinates early on. This commit fixes both X,Y limits, whereas commit d4b6bf4 only fixed Y.
@gbburkhardt thanks for the response. We will change this in the private repository for now. |
@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. |
From https://github.com/WorldWindEarth/WorldWindJava/commits/develop/ We got the following commits (partial lists): 57b265b 4afe979 3388e26 e45b49d a4bf62d 56a90c4 f4c1734 2f92b3e 6225f20 e8262dc 9e6e504 81731e8 843d22f From https://github.com/NASAWorldWind/WorldWindJava/commits/develop/ We got the following commits - Fix display of context menu in ContextMenusOnShapes demo. (NASAWorldWind#274) - Delete local copy of worldwind/render/TextRenderer in favor of version that is maintained by JOGAMP. Update JOGL jar files with released version 2.5.0, build Build: 2.5-b1533-20230818. That build i… - Implementing formatting rules. (NASAWorldWind#271) - New JOGL to fix linux crashes (NASAWorldWind#270) - Remove extraneous source (NASAWorldWind#269) - Fixes for DPI scaling. Mouse and select events now deliver GL surfac… (NASAWorldWind#262)
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 #262 (comment). 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