Fixes script editor debug menu on sessions other than 1
Fixes breakpoint toggle from menu in sessions other than 1
Removes execution display when switching to non-breaked sessions
This change defines additional theme contexts for editor
branches to prevent theme leaking between the default
theme, the project theme, and the editor theme.
- Both editor window and EditorNode define an editor-specific
context with the editor theme and the default theme.
- The 2D viewport defines a project-specific context with
the project theme and the default theme.
- Theme editor preview tabs define the default-only context
with the default theme.
Additionally, the default theme context now only includes
the project theme for running projects (both export and debug).
This prevents the project theme from leaking into the editor.
This commit also does a little clean up on the theming aspects
of the EditorNode.
This should result in some noticeable performance improvements,
aside from fixing bugs due to conflicts in logic.
This also simplifies some related code identified while debugging.
Removes documentation generation (docgen) from the GDScript compiler to
its own file. Adds support for GDScript enums and signal parameters and
quite a few other assorted fixes and improvements.
- Simplify and update its logic.
- Simplify EditorScript.
- Improve EditorNode and other relevant includes.
- Fix scene-based path in the movie writer when
reloading a scene.
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.
* 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>
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.
It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).
We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).
Also fixed "cf." Frenchism - it's meant as "refer to / see".
Implement `GDScriptTextDocument::willSaveWaitUntil` to clean up outdated documents before saving,
then update the document in `GDScriptTextDocument::didSave`.
Previously, external editing via lsp would modify the modified time of the script,
which caused the internal display of the script to not be refreshed when refocusing
the engine.
Now saving the script externally via lsp will automatically refresh the internal
display.
Removes separate `Command` key (use `Meta` instead).
Adds an event flag to automatically remap `Command` <-> `Control` (cannot be set alongside `Control` or `Meta`).
This reverts commit 4b817a565c.
Fixes#64988.
Fixes#64997.
This caused several regressions (#64988, #64997,
https://github.com/godotengine/godot/issues/64997#issuecomment-1229970605)
which point at a flaw in the current logic:
- `Control::NOTIFICATION_ENTER_TREE` triggers a *deferred* notification with
`NOTIFCATION_THEME_CHANGED` as introduced in #62845.
- Some classes use their `THEME_CHANGED` to cache theme items in
member variables (e.g. `style_normal`, etc.), and use those member
variables in `ENTER_TREE`, `READY`, `DRAW`, etc. Since the `THEME_CHANGE`
notification is now deferred, they end up accessing invalid state and this
can lead to not applying theme properly (e.g. for EditorHelp) or crashing
(e.g. for EditorLog or CodeEdit).
So we need to go back to the drawing board and see if `THEME_CHANGED` can be
called earlier so that the previous logic still works?
Or can we refactor all engine code to make sure that:
- `ENTER_TREE` and similar do not depend on theme properties cached in member
variables.
- Or `THEME_CHANGE` does trigger a general UI update to make sure that any
bad theme handling in `ENTER_TREE` and co. gets fixed when `THEME_CHANGE`
does arrive for the first time. But that means having a temporary invalid
(and possibly still crashing) state, and doing some computations twice
which might be heavy (e.g. `EditorHelp::_update_doc()`).
As announced in https://godotengine.org/article/godot-4-will-discontinue-visual-scripting,
Godot maintainers have agreed to discontinue the current implementation of
our VisualScript language.
The way it had been designed was not user-friendly enough and we did not
succeed in improving its usability to actually make it a good low-code
solution for users who need one.
So we prefer to remove it for Godot 4.0 and leave the door open for new,
innovative ideas around visual scripting, to be developed as plugins or
extensions now that Godot provides sufficient functionality for this
(notably via GDExtension and the godot-cpp C++ bindings).
The current module has been moved to a dedicated repository (with full Git
history extracted with `git filter-branch`):
https://github.com/godotengine/godot-visual-script
It can still be compiled as a C++ module (for now, but will likely require
work to be kept in sync with the engine repository), but our hope is that
contributors will port it to GDExtension (which is quite compatibile with
the existing C++ module code when using the godot-cpp C++ bindings).
