Send mouse-enter notification, when viewport receives a mouse motion event #90444
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…event Ensure, that a `SubViewport` receives a `NOTIFICATION_VP_MOUSE_ENTER`, when an `InputEventMouseMotion` is sent to a viewport, that currently doesn't have the mouse inside. In the following case the changed code makes a difference: By default the viewport has the state, that the mouse is not over the viewport. When the user pushes an `InputEventMouseMotion` to a `SubViewport`, then because of the default state, the Viewport assumes, that the mouse is not over itself. With this change, the Viewport automatically switches its state. Make necessary adjustments to unit-tests.
Sauermann
force-pushed
the
fix-push-input-mouse-notification
branch
from
aed2146 to
3e14688
Compare
Member
|
In the MRP and without this PR, when you hold mouse button, the motion events are received. It's happening without While you say these changes are a hack, technically receiving a mouse event means the mouse is over viewport, so I think it's correct. Though the mouse over is never dropped, not sure if it has undesirable effects. Maybe it should be documented that you should manually drop mouse over if you pushed mouse events to viewport. |
Contributor
Author
|
Superseded by #99890 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ensure, that a
SubViewportreceives aNOTIFICATION_VP_MOUSE_ENTER, when anInputEventMouseMotionis sent to a viewport, that currently doesn't have the mouse inside.In the following case the changed code makes a difference: By default the viewport has the state, that the mouse is not over the viewport.
When the user pushes an
InputEventMouseMotionto aSubViewport, then because of the default state, the Viewport assumes, that the mouse is not over itself and acts accordingly, leading to the behavior described in #89757.With this change, the Viewport automatically switches its state.
Make necessary adjustments to unit-tests.
The behavior got introduced by #88992, which by itself was a step in the right direction, but caused undesired behavior.
This change would have introduced problems before #89920, because sometimes it was possible, that a Viewport received mouse motion events even when the mouse was outside of the viewport.
Resolve #89757 and also duplicate #90413. (I have verified the MRPs of both reports)
Supersedes #89868
Instead of this change, the problem can also be solved, by updating the documentation and explaining, that the user not only needs to push input events to
SubViewports, but is also responsible for sendingNOTIFICATION_VP_MOUSE_ENTERandNOTIFICATION_VP_MOUSE_EXITwhen necessary.While I believe, that this documentation change would be conceptually the correct way to go forward, it would be less user-friendy and I don't forsee direct problems with the approach of this PR, because before #88992 the
SubViewportsbe default had as stategui.mouse_in_viewport == true.All in all, this PR seems a bit hacky to me.