Skip to content

Fix display of context menu in ContextMenusOnShapes demo. #274

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Mar 26, 2024

Conversation

gbburkhardt
Copy link
Contributor

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

… of AWT screen coordinate when creating SelectEvent.
Copy link

@thwe74 thwe74 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested on Windows 11 (64 Bit) with OpenJDK 17. And the issue is fixed.

Copy link

@thwe74 thwe74 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested on Windows 11 (64 Bit) with OpenJDK 17. And the issue is fixed.

@thwe74
Copy link

thwe74 commented Jan 9, 2024

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.

Mouse_Image_Move.mp4

gbburkhardt added a commit to gbburkhardt/WorldWindJava that referenced this pull request Jan 9, 2024
@gbburkhardt
Copy link
Contributor Author

@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.

@thwe74
Copy link

thwe74 commented Jan 10, 2024

@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.
@gbburkhardt
Copy link
Contributor Author

@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.
@thwe74
Copy link

thwe74 commented Jan 11, 2024

@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
Copy link

thwe74 commented Jan 11, 2024

@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.
150

@gbburkhardt
Copy link
Contributor Author

@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.

…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
Copy link
Contributor Author

@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.

@thwe74
Copy link

thwe74 commented Jan 12, 2024

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
Copy link

thwe74 commented Jan 12, 2024

@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.

Copy link
Member

@markpet49 markpet49 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested on Windows, Linux, M series Mac. Looks good! Thanks for the contribution.

@markpet49 markpet49 merged commit 8f3c491 into NASAWorldWind:develop Mar 26, 2024
quonn77 added a commit to quonn77/WorldWindJava that referenced this pull request Apr 23, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants