* Deprecates GDNative in favor of a simpler, lower level interface.
* New extension system allows registering core engine classes.
* Simple header interface in gdnative_interace.h
Renamed incorrect "hint" variable names to "usage" in
`_get_property_list()`, as "hint" implies one of the PROPERTY_HINT_*
values, which is not the case here.
-Advanced Settings toggle also hides advanced properties when disabled
-Simplified Advanced Bar (errors were just plain redundant)
-Reorganized rendering quality settings.
-Reorganized miscelaneous settings for clean up.
-For inspector refresh, the inspector now detects if a property change by polling a few times per second and then does update the control if so. This process is very cheap.
-For property list refresh, a new signal (property_list_changed) was added to Object. _change_notify() is replaced by notify_property_list_changed()
-Changed all objects using the old method to the signal, or just deleted the calls to _change_notify(<property>) since they are unnecesary now.
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
And fixups:
- Add missing bindings in RenderingServer
- Remove duplicate ArrayMesh enum bindings (they're in Mesh already)
- Remove redundant _unhandled_key_input binding in Control (it's in Node
already)
unhandled_key_input changed to unhandled_button_input. Controls can set a 'shortcut_context' which they can then use to determine if their shortcuts should be triggered or not, based on if the viewport's focused GUI control is a child of their 'shortcut context'.
The return type for `_make_custom_tooltip` is clarified as Control, and users
should make sure to return a visible node for proper size calculations.
Moreover in the current master branch, a PopupPanel will be added as parent
to the provided tooltip to make it a sub-window.
Clarifies documentation for `Control._make_custom_tooltip`, and shows how to
use the (until now undocumented) "TooltipPanel" and "TooltipLabel" theme types
to style tooltips.
Fixes#39677.
This makes it clearer that it expects a node type as a string
(such as "Label") instead of a type like "TYPE_ARRAY".
This is backwards-compatible since only the name of the parameter
is changed, not its order.