Enforce that custom nodes and resources created via the "Create New Node" dialog, should permanently retain their original type (script). This means:
- Type continuity: It should be impossible for the user to (accidentally) clear the original script of a custom node that was created via the "Create New Node" dialog.
- Extensibility: The user should be able to extend custom types as usual (create a script that inherits the original type and replace the original script of that node with his own). However, if he then clears his extension-script from that node later on, the custom type should revert to its original script instead of becoming a non-scripted type.
Currently, if a user or some resource exposes a path in a script,
if this references a resource path it will be saved as a full path.
This will make refactoring not work if the resource pointed towards
changes location or is renamed.
This change makes it so an uid:// path is saved internally in case
a path to a resource has been selected, effectively making it refactor proof.
This helps with confusion over how selecting a key with a duplicate
value won't be selected as only the first entry with a particular value will
be selected.
This change introduces a new theme configuration struct to be
passed to the aforementioned routines to better control reuse
of styles and definitions in the generator.
Everything not passed and not explicitly shared is scoped so it
is not automatically accessible throughout the routine. This
should ensure that the decision to share styles is a conscious one.
In the future we will try to reduce the number of unique definitions
and share most of it. This PR is a stepping stone on this path.
This also puts the effort into separating redefinitions of
default theme items vs custom types introduced only by the editor.
In a few cases where editor-specific definitions need to reference
default definitions we simply fetch them from the theme. It's not
ideal and hides the dependency a bit, but hopefully these cases
will be abstracted properly in due time.
This change introduces a new EditorThemeManager class
to abstract theme generatio and its subroutines.
Logic related to EditorTheme, EditorColorMap, and editor
icons has been extracted into their respective files with
includes cleaned up.
All related files have been moved to a separate folder to
better scope them in the project. This includes relevant
generated files as well.
This behavior is inspired by Blender (except it's the other way
around to preserve the current default behavior).
Trying to enable a single enabled value with Cmd held will invert the
current flags, which makes enabling all flags but one faster.
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.
Also start organizing editor-specific GUI components
into a dedicated folder, `editor/gui`.
Also move `editor_file_server` next to the rest of debugger classes.
* Scene tab
* Animation name list in Animation panel
* Feature profile name list in Editor Feature Profile dialog
* Layout names in editor layout menu
* Subresource list in Inspector dock
* Resource type shown in EditorResourcePicker
* Enum dropdowns in inspectors: We'll eventually allow auto translating
these after implementing a way to opt-out auto translation on a
property-by-property basis and a way to extract enumerators.
* This solution is much cleaner than the one in 3.x thanks to the use of callables.
* Works without issues in any language (no need to worry about camel or snake case).
* Editor code uses a compatibility function (too much work to redo).
Fixes#59899
* Remove unused `EditorPropertyMember` and related hints, previouly used by
VisualScript. Such logic should be implemented in the VS module itself.
* As the above broke compatibility with the VS module, clean up the other
hacks that were still in core in support of VisualScript.
* `PROPERTY_USAGE_INTERNATIONALIZED` was only used in Object's
`get_translatable_strings()`, which is a legacy function not used anywhere.
So both are removed.
* Reordered some usage flags after the above removal to minimize the diff.
* General clean up.
Fixes#30203.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>