Skip to content
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

Fix for #2327 Mouse pointer moves to centre of canvas on click in OpenGL3 with Swing #2328

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

terranprog
Copy link

Modify FlyByCamera to only hide the mouse cursor when the user actually rotates the camera, rather than when the user first presses the left mouse button. When the mouse is clicked, instead of immediately hiding the cursor, a flag (hideCursorOnNextRotate) is set. If and when a rotate is detected, the flag is checked and if true the cursor is hidden and the flag is cleared.

… click in OpenGL3 with Swing

Modify FlyByCamera to only hide the mouse cursor when the user actually rotates the camera, rather than when the user first presses the left mouse button.
When the mouse is clicked, instead of immediately hiding the cursor, a flag (hideCursorOnNextRotate) is set. If and when a rotate is detected, the flag is checked and if true the cursor is hidden and the flag is cleared.
@capdevon
Copy link
Contributor

capdevon commented Nov 15, 2024

I tested the behavior of FlyByCamera with LWJGL2 and LWJGL3 in combination with Swing. In both cases, setting flyCam.setDragToRotate(true) repositions the mouse pointer to the center of the Canvas after the left mouse button is released to enable camera rotation. This behavior does not occur in typical applications that do not use Swing, where the mouse pointer returns to its last position at the time of the click.

While this isn’t overly inconvenient and you can get used to it, it’s worth noting that FlyByCamera is built into the SimpleApplication class by default and is likely used by thousands of applications. Changing its behavior could introduce more problems than benefits without extensive testing. FlyByCamera was probably not designed specifically for use with Swing, but rather for simple JME applications.

If your goal is to develop an editor with Java Swing + JME, I recommend creating a custom EditorCamera by duplicating the FlyByCamera code and adapting it to your specific needs. JME is designed to be customizable in almost all of its components.

Copy link
Contributor

@codex128 codex128 left a comment

Choose a reason for hiding this comment

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

If these changes introduce functionally different behaviors (particularly on glfw applications), I'd suggest adding an option to disable or enable the changes, with it disabled by default.

Also, I don't foresee there being any problems, but it would be good to make sure nothing unexpected happens when using glfw with any opengl versions along with these changes.

if(value) {
hideCursorOnNextRotate = true;
}
else {
Copy link
Contributor

Choose a reason for hiding this comment

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

Change to } else { (one line)

if(hideCursorOnNextRotate) {
inputManager.setCursorVisible(false);
hideCursorOnNextRotate = false;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This could be changed to

if (!canRotate) {
    return;
} else if (hideCursorOnNextRotate) {
    inputManager.setCursorVisible(false);
    hideCursorOnNextRotate = false;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants