When changing `viewport_path`, the `proxy`'s target is changed to a new placeholder.
Add a flag `vp_changed` to prevent calling `setup_local_to_scene` (mainly called by toggling `resource_local_to_scene`) when the target viewport has not changed.
Currently mouse hovering doesn't update the state, when collision objects
or the camera move.
This PR fixes this problem by taking the mouse position from the viewport
and not from a nonexistent previous event.
Since previous events could potentially be a long time ago, their
modifier-key state might be outdated. This PR fetches the current
status of modifier-keys from `Input`.
These changes allow the removal of some class-variables and making
additional simplifications.
When a Viewport is not directly attached to the screen, the
function `Viewport::get_mouse_position` can't rely on
`get_screen_transform`, because that function is ambiguous in
these situations.
In these cases it is necessary to use the mouse position from
the most recent mouse IputEvent.
`NOTIFICATION_CHILD_ORDER_CHANGED` could be triggered, while there
was an inconsistent state:
- parent node no longer had child listed as child
- child node still had parent node listed as parent
Bring these two in sync, before emitting the notification.
AnimationNodeBlendSpace2DEditor:
- `!tree` is always false, because it is checked a few lines above
CurveEdit:
- grabbing != GRAB_NONE is redundant
GradientTexture2DEdit:
- grabbed != HANDLE_FROM is redundant
- grabbed != HANDLE_TO is redundant
Viewport:
- index is not used afterwards
- In these cases `gui.mouse_focus` is always valid. Move check to a DEV_ASSERT
- simplify `stopped` calculation
Partially Revert "Create a virtual mouse move event after moving child nodes"
This reverts parts of commit ce10ca6979.
The problem was that the the mouse-move event interacted in unexpected ways.
The functionality of `push_unhandled_input` has changed so that it no
longer propagates input events to SubViewports.
This makes it less predictable and it should be deprecated in favor of
`push_input` which provides the same functionality and more.
Also this deprecation simplifies the Viewport-API by reducing the methods
for pushing input events, so that users don't need to worry about when
to use which function in order to insert input events.
A single mouse click can cause multiple actions, which contradicts
the paradigm that a single Input Event should cause only a single
action.
The solution consists of two parts:
1. Physics Picking as the last step during viewport input event
handling, currently doesn't set the event as handled. This PR sets
the event as handled in the case of physics picking.
2. After an InputEvent is processed by a SubVieportContainer, it is
sent to its parent, even if it set as handled within the SubViewport.
This PR adds an additional test to check if the event is handled
before propagating the event to the parent Control.
