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.
Fixes the issue by adding a mechanism by which the functions that were
previously disappearing can be profiled too. This is optional with
an editor setting, since collecting more information naturally slows the engine
further while profiling.
Fixes#23715, #40251, #29049
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.
* This implementation adds threads on the side of the client (script debugger).
* Some functions of the debugger are optimized.
* The profile is also now thread safe using atomics.
* The editor can switch between multiple threads when debugging.
This PR adds threaded support for the script language debugger. Every thread has its own thread local data and it will connect to the debugger using multiple thread IDs.
This means that, now, the editor can receive multiple threads entering debug mode at the same time.
- Use the name, file path and line number of the caller that invokes
`GD.PushError` and `GD.PushWarning` instead of the location in the C++
`runtime_interop.cpp` file.
- Improvements to getting the C# stack trace.
- Use C# type keywords for built-in types in method declarations.
- Remove extra space before each parameter in method declarations.
- Skip one more frame to avoid `NativeInterop.NativeFuncs`.
- Skip methods annotated with the `[StackTraceHidden]` attribute.
- Improvements to `ScriptEditorDebugger` when source is in project.
- Avoid overriding error metadata when the source is inside the
project file.
- Use the source function in the title when the source is inside
the project file.
Users that use these methods would expect the reported location printed
by these methods to correspond to a location in their project source files.
Specifically, they'd expect to see the file path and line number at which
they call these methods, and not the location of the C++ code (which is
always the same). Now, these methods are a lot more useful since users
can know which line in their source code printed the error/warning.
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.
- Use the right stack frame info as title of the error.
- Use the actual C# exception type as error for exceptions raised from C#.
- Show the right language instead of always **C++ Error**.
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".
- Changes `TextServer.string_get_word_breaks()`
- Returns pairs of boundary start and end offsets
- Accepts `chars_per_line` to return line breaks
- Removes `String::word_wrap()`
Co-authored-by: bruvzg <7645683+bruvzg@users.noreply.github.com>
Now splitted into two classes:
- EditorDebuggerPlugin (RefCounted).
- EditorDebuggerSession (abstract).
This allows the EditorPlugin to be in control of the debugger plugin
lifecycle, be notified when sessions are created, and customize each of
them independently.
We should slowly transition the various profilers and captures in
ScriptEditorDebugger to their own plugins, and decouple
ScriptEditorDebugger from it's UI part (making it the "real"
EditorDebuggerSession potentially dropping the wrappers).
`set_tooltip` -> `set_tooltip_text`
`get_tooltip` -> `get_tooltip_text`
For consistency:
`get_button_tooltip` -> `get_button_tooltip_text`
And the `tooltip` parameter in `add_button` was renamed to `tooltip_text`
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()`).
