Changes to reduce the latency between changing node selection in the editor and seeing the new node reflected in the Inspector tab
- Use Vector instead of List for ThemeOwner::get_theme_type_dependencies and related functions
- Use Vector instead of List for ThemeContext::themes, set_themes(), and get_themes()
- Add ClassDB:get_inheritance_chain_nocheck to get all parent/ancestor classes at once, to avoid repeated ClassDB locking overhead
- Update BIND_THEME_ITEM macros and ThemeDB::update_class_instance_items to use provided StringNames for call to ThemeItemSetter, instead of creating a new StringName in each call
These changes reduce the time taken by EditorInspector::update_tree by around 30-35%
Added TreeItem::last_child to avoid needing to iterate through all children to get to the end. This mainly helps in cases where one TreeItem has many children (1000s), and new children are added to the end, as each add had to iterate through all previously added children.
When a FlowContainer had a TextureRect child using any of the EXPAND_FIT_* expand modes, it could crash when changing the FlowContainer's minimum size, or that of its children. This was due to the TextureRect resizing in FlowContainer::_resort, updating its minimum size, and triggering another _resort. If the TextureRect's minimum size changed in a way that caused any of the FlowContainer's children to be put on a different line, it could repeatedly cause _resort to be called again, moving the children back and forth between the old and new lines.
This change is for FlowContainer::_resort to give a warning for TextureRects with EXPAND_FIT_* expand modes when multiple lines are used, and just keep the TextureRect size the same in that case. This is similar to the check added to AspectRatioContainer in godotengine#73396, but attempting to still support it in FlowContainer when possible. In the case where the TextureRect is forced to stay the same size, there may be some overlap between the FlowContainer's children, but should no longer crash.
Prior to this fix, scrolling via mouse drag on touchscreen devices, and
drag&drop operation on a `TreeItem` element would conflict with each other
preventing the drag scroll from being released when the mouse button is
released.
The issue is addressed by disabling drag&drop when drag scrolling is ongoing.
When a FlowContainer was scaled, the point at which a line wraps would
also be scaled. This would cause a FlowContainer to have lines that did
not fit the container.
FlowContainer no longer factors its scale when resorting children.
Fixes#93439
When calculating minimum size, GridContainer only looks at children that are
returned from `as_sortable_control()`. That defaults to only showing children
visible in the tree, so if the grid has a hidden parent the minimum size
becomes (0, 0).
After this change only the child itself needs to be visible, making
`GridContainer::get_minimum_size()` behave the same way as other controls.
Fixes#91722.
When Container::queue_sort() is called, pending_sort is set to true to indicate when a call to _sort_children() is queued, to avoid queueing multiple calls. Container::_sort_children() sets pending_sort back to false when finished, but did not do this when the container was not inside the tree. This would allow cases where queue_sort() could be called just before removing from the tree, causing _sort_children() to never reset pending_sort, preventing any future queue_sort() calls from queueing again.
One case where this happened was with the "Saving Scene" progress bar in the editor - when saving for the first time (or the first time the progress bar popup otherwise appeared in the editor), _sort_children() would be called successfully. After the progress bar popup was hidden, then shown again on future saves, _sort_children() would not be called again, resulting in the progress bar not taking up as much space as it should.
This issue used to be avoided by setting pending_sort to false immediately on NOTIFICATION_ENTER_TREE - however, this would allow multiple calls to be queued at the same time when entering the tree (#92644). The multiple calls was fixed recently by removing this assignment, but this also made possible the case where pending_sort is never reset.
This change sets pending_sort back to false in _sort_children() whether or not it's in the tree. Since this is done in a deferred call, it should still avoid the previous issue of multiple calls being queued at once on entering the tree.
Fixes#92971
