This adds binds for GraphEdit/GraphElement/GraphNode, which were
skipped before due to a rework. This also adds binds for Window,
which was skipped before due to a complicated code organization.
Also adds theme cache entries/direct cache access to a few places
that previously missed it. Some theme properties are now exposed
to other classes via friendships or public getters for convenience.
This removes all string-based theme access from scene/ classes.
This allows to include script_instance.h directly in the
generated gdvirtual.gen.inc, and remove excessive includes
from the codebase.
This should also allow Resource to use GDVIRTUAL macros,
which wasn't possible previously due to a circular dependency.
This commit adds the default theme context, which replaces
the need to manually check the project and the default theme
all the time; simplifies related code.
It also adds framework for custom theme contexts, to be used
by the editor. Custom contexts can be attached to any node,
and not necessarily a GUI/Window node. Contexts do no break
theme inheritance and only define which global themes a node
uses as a fallback.
Contexts propagate NOTIFICATION_THEME_CHANGED when one of their
global themes changes. This ensures that global themes act just
like themes assigned to individual nodes and can be previewed
live in the editor.
The only use of that function can be replaced by `_notify_transform`,
which makes the `propagate_call` unnecessary.
As far as I can tell, the `data.blocked`-checks of `propagate_call`
are not needed in this case, because `_invalidate_global_transform`
causes no user-noticeable changes.
Previously the `p_reversed` parameter didn't influence the order
in a correct way.
Also script overridden _notification functions were not called in
the correct order.
To fix this some `notification` functions had to add a `p_reversed`
parameter.
This made it necessary to adjust cpp-bindings.
Co-authored-by: David Snopek <dsnopek@gmail.com>
Made Viewport::_cleanup_mouseover_colliders queue up mouse_exit and
mouse_shape_exit signals to emit and at the end of the function's
execution to avoid potential crashes.
Integer scaling is achieved (after aspect expansion) by "lying" to the
stretching code about the window's size, telling it that it's always an
integer multiple of the viewport so that it only gets stretched to an
integer factor.
This approach works with all stretch and aspect modes and doesn't
require handling for each, only requiring to "loosen up" some
self-excluding conditions (in other words, replacing some `else if`s
with just `if`s) regarding viewport offset and margin calculation (black
bars).
Includes a tiny usability change that adds a range hint for the content
scale factor between 0.5 to 8.0.
Co-Authored-By: Hugo Locurcio <hugo.locurcio@hugo.pro>
Previously for InputEvents there was no distinction between
Window-area and Viewport-area.
This was problematic in cases where stretching was used and the Window
contained black bars at the sides of the Viewport.
This PR separates the area of Window and Viewport regarding InputEvents.
Saving a subscene causes the main scene to be re-instantiated. And the resource
instance in the main scene will be reused when the main scene is re-instantiated.
So for resources with `resource_local_to_scene` enabled, resetting state may be
necessary (at least for `ViewportTexture`).
This is needed to allow 2D to fully make use of 3D effects (e.g. glow), and can be used to substantially improve quality of 2D rendering at the cost of performance
Additionally, the 2D rendering pipeline is done in linear space (we skip linear_to_srgb conversion in 3D tonemapping) so the entire Viewport can be kept linear.
This is necessary for proper HDR screen support in the future.
The previous implementation for signals mouse_entered and mouse_exited
had shortcomings that relate to focused windows and pressed mouse buttons.
For example a Control can be hovered by mouse, even if it is occluded by
an embedded window.
This patch changes the behavior, so that Control and Viewport send
their mouse-enter/exit-notifications based solely on mouse position,
visible area, and input restrictions and not on which window has
focus or which mouse buttons are pressed. This implicitly also
changes when the mouse_entered and mouse_exited signals are sent.
This functionality can not be implemented as a part of
Viewport::_gui_input_event, because of its interplay with Windows and
because Viewport::_gui_input_event is based on input and not on
visibility.
This PR removes the error-message, which is currently expected to happen.
The task of correctly fixing the underlying problem of window popup
closing is more complex, so this PR solves the immediate
error-notification-problem.
When the parent `SubViewportContainer` ignores mouse with
`MOUSE_FILTER_IGNORE` and also when the mouse is over a `Control`-node,
then the `SubViewport` shouldn't create mouse-move-events for passive
hovering.
Propagate `InputEvents` without position either
- during the Input-stage, when it has focus or
- during the Unhandled-Input-stage, otherwise
This makes sure that Gui-Input happens in the correct order.
Move "Unhandled key Input" handling before "Unhandled Input" handling,
so that Unicode input with Alt / Ctrl modifiers are sent to the nodes
in the correct order.
Change the default focus mode of `SubViewportContainer` from
`FOCUS_NONE` to `FOCUS_CLICK`, to automatically remove focus from
other `Control`-nodes, when clicking inside a `SubViewport`.
Currently the input-handled-state for different events can interfere with
each other.
This PR makes sure, that the input_handled_state is reset before
processing and InputEvent during physics-picking.
At the moment it is impossible to distinguish between focused and
unfocused embedded Windows.
Add a new `theme_item` that is used for coloring the border of
unfocused Windows.
`vp_pending` is a flag indicating to wait for `ViewportTexture::_setup_local_to_scene`
to be called. Once this method is called, no matter whether the setup will fail or not,
it needs to be reset to `false`.
CPPcheck found most of them.
no need to assign the variable twice:
- AnimationTrackEditTypeAudio
- SSEffects
variable is assigned in all if-else clauses:
- EditorHelp
- AndroidInputHandler
- MenuBar
- ShaderCompiler
same if clause:
- ItemList
clearing an empty bitfield has no effect:
- Viewport
Currently the window receives a focus-out notification, directly after
it popup, because currently the signal is sent deferred.
The original intention was that the previously focused window must
receive a focus-out notification.
This change makes the notification more precise by only sending the
focus-out to the previously focused window.
SceneTree overrides the virtual `process` and `physics_process` methods
that it inherits from MainLoop. These methods return a boolean that
determines if the main loop should end.
The SceneTree was ignoring the returned boolean, so scripts inheriting
from SceneTree that override these methods and return true didn't exit
the main loop. Now the boolean is checked.
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.
When node tree `A` is not in the tree, `remove_child(B)` will not
automatically clean up the owners of `B` and `B`'s child nodes.
This is convenient for implementing operations like `replace_by()`,
but may have hidden dangers when manipulating the rest of the tree
`A`.
This commit makes it safe to manipulate the rest of `A` after freeing
`B`.
The associated `ViewportTexture`s will update the `viewport_path`
in time when the `Viewport`'s nodepath is changed (caused by renaming
the node names or moving in the SceneTree dock).
If the target `Viewport` is changed by resetting the `viewport_path`,
the `ViewportTexture`s will be re-setup and emit `changed` signal in
time.
* Node processing works on the concept of process groups.
* A node group can be inherited, run on main thread, or a sub-thread.
* Groups can be ordered.
* Process priority is now present for physics.
This is the first steps towards implementing https://github.com/godotengine/godot-proposals/issues/6424.
No threading or thread guards exist yet in most of the scene code other than Node. That will have to be added later.
* Adding and removing child nodes is now constant time, speed up should be huge.
* Searching for node paths as in ("path/to/node") should be far faster too.
This changes the children management and makes it a hashmap, optimizing most StringName based operations.
Most operations should be severe speed up without breaking compatibility.
This should fix many issues regarding to node access performance, and may also speed up editor start/end, but benchmarks are needed. So if you want to test, please make some benchmarks!
Further performance improvements will be done in the future by removing NOTIFICATION_MOVED_IN_PARENT and replacing by something less laborious.
With change 104392e the code to update node indices on removal was erronously removed.
The out of date indices would cause crashes while selecting nodes in a graph editor (e.g. animation tree) and selected nodes are oftern pushed to beginning or end of the child list for the parent.
* This notification makes node children management very inefficient.
* Replaced by a NOTIFICATION_CHILDREN_CHANGED (and children_changed signal).
* Changed Canvas code (and similar) to use the above signal, to perform more efficiently.
This PR breaks compatibility (although this notification was very rarely used, even within the engine), but provides an alternate way to do the same.
It is required for the changes in #75627 to be entirely effective.
* Make placeholder in editor layout dialog translatable.
* Make messages in scene import settings dialog translatable.
* Mark theme override property categories for translation.
Fixes#75084.
The clamp_to_embedder setting was added in 8be16e0704,
but was not set on any of the in-editor dialogs.
This patch sets `clamp_to_embedder` on editor dialogs so they cannot be dragged out of the frame.
This also modifies `clamp_to_embedder` so a window is clamped to the bounds of an embedder when
it pops up and when the parent is resized.
This solves the problem, that mouse events get sent to SubViewports
even if they are outside of the visible area of the SubViewport.
This changes makes SubViewportContainer::unhandled_input redundand.
Shortcut Events now need to be distributed via push_input, in order for
them to be able to reach SubViewports.
In the editor, it was possible to set the size of a `SubViewport` even
in cases where a parent `SubViewportContainer` had stretch enabled.
This PR disables editing a `SubViewport.size` while the parent disallows
it and it makes necessary adjustments during `NOTIFICATION_ENTER_TREE`.
After a scene reload a mouse cursor updates is performed via a
InputEventMouseMotion, that is exposed to the user.
The state of Input is however not adjusted to this InputEventMouseMotion
which can lead to inconsistencies.
This PR makes sure, that it is not exposed to the user.
It utilizes the method of Viewport::_process_picking for marking
events that are not sent to the user, so that this function doesn't
need to be changed.
With the 4.x-introduction of Windows the previous method for
color picking was no longer working.
This PR uses the following approach to reintroduce color-picking.
When the Color-Picking-Button is pressed, a quasi-screenshot of the
Window-content is created and displayed in a new Popup-Window.
This new Window allows selecting colors by Mouse-Click.
A Preview of the targeted Color is also displayed.