-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve GDExtension Tools Integration with Editor Debug Tooling #86721
Conversation
Please open a proposal to track this and discuss the specifics of this feature |
@AThousandShips done - godotengine/godot-proposals#8777 |
f38b954
to
64e145c
Compare
5f46704
to
39ea285
Compare
2e04278
to
8ab643d
Compare
Hi, would someone me able to tell me whether the failure is related to my change or something that pre-exists in |
Thanks! At a high-level, I think this is a great addition, since it's making something that's possible via Godot modules also be possible via GDExtension (and addons). I'm not really familiar with the debugger API, but for the most part, the code here looks like a thin layer over |
I'd also add that if there are other bits from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not the most familiar with the debugger code, but this is mostly exposing what's there for extensions. Overall it looks fine to me.
Could you squash the commits? See PR workflow for instructions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to expose ScriptDebugger
as a separate class?
I feel that class exists in core mostly for historical reasons.
Does it make sense to move the exposed functions directly to EngineDebugger
?
E.g.:
core_bind::EngineDebugger::insert_breakpoint
Unfortunately, you may be the person most qualified to answer the questions you pose. :-) |
I have to agree with David, really entirely your call, I can certainly align those there if you'd prefer. |
fa019bf
to
1fb8987
Compare
Given there doesn't seem to be any objection, I will say let's do that. It's already confusing enough to have I already had plans to move more of the debugger default features to the plugin interface (while still shipping them as part of Godot), so I will take a chance there to see if we can get rid of the whole ScriptDebugger concept internally too. |
Sounds good, then I'll amend the PR over the weekend and ping you when its ready for a review from your side on the particulars to make sure that the direction and goals are aligned to what you have in mind 👍 @Faless |
Hi @Faless, I have a few questions about this work. I was reviewing and testing my changes in a local build to make sure I hadn't missed any additions needed for this to work well for our script language plug-in, and I came across a hack I had used to integrate with the TypedArray<Node> nodes = editor_node->find_children("*", "EditorDebuggerNode", true, false);
if (nodes.size() == 1) {
// Wire this signal so when user selects a frame we can handle that here.
Node* editor_debugger_node = Object::cast_to<Node>(nodes[0]);
editor_debugger_node->connect("goto_script_line", callable_mp(this, &OrchestratorScriptView::_goto_script_line));
} The What I was considering was adding a new method on void goto_script_line(const Ref<Script>& p_script, int p_line); Then, inside
So it seems In addition, I also need a way to react to |
1fb8987
to
d77588c
Compare
d77588c
to
40ea1b0
Compare
The build failures seem to be unrelated as |
This should be fixed after rebasing. |
40ea1b0
to
d1a07cd
Compare
@akien-mga @Faless is it possible to still get this into 4.3? It would be super helpful for us to have debugger support in the editor and this is a blocker for that. |
It's marked for 4.3 so unless that is changed it's still planned for 4.3, wait and see |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic job! 🏆 , and sorry for the long delay between reviews.
I was worried of the potential misuse of set_lines
/set_depth
which can potentially break debugging but I couldn't figure out a better solution, and it's better to have this than not in 4.3.
So I've approved this, but also suggested marking those methods as experimental.
Thank you for your patience and the great work.
The ID is a bit of an implementation detail, but it's indeed the "tab number".
I think indeed those signals could be exposed via the Maybe |
d1a07cd
to
03bf63e
Compare
Thanks for the feedback @Faless, I've addressed your recommendations with the documentation and I've added the 3 methods as virtual methods on the |
03bf63e
to
893a2b4
Compare
893a2b4
to
8577340
Compare
Thanks! |
Oh no... as I mentioned in my comment, those should probably have been signals not virtual methods :( |
No worries, I can send another PR to follow-up on this if that's acceptable @Faless @akien-mga, just lmk. |
@Naros I'll let you know in case, it's not the end of the world indeed, just a bit weird, we usually prefer virtual methods for things that needs overriding and either are frequently called (they're faster than signals), or when we need to receive a return (which is not the case for those function). At the same time, the plugin aims to be "self-contained", so the virtual method can make sense, and might not be worth changing. Sorry for the noise, I think in the end we'll leave it as it is now 😅 |
This PR aims to address several issues around GDExtension and Debug Tooling within the Editor.