A scripting language extension for Godot using GDExtension.
Describe the problem or limitation you are having in your project
When a GDExtension plug-in implements the ScriptExtension and ScriptLanguageExtension contracts, part of these contracts allow the script to submit commented documentation that can be rendered in the editor's documentation panels, i.e.:
The problem is that once the documentation has been generated and shown to the user in the editor, there is no way for a GDExtension-based solution to synchronize the documentation view. The user has to close the documentation tab and then research for the class and re-open the documentation for it to update.
In the engine's source, this synchronization is hidden behind the tight coupling of ScriptEditor and EditorHelp. When a script is saved in the ScriptEditor, this automatically causes the documentation for the script to be repopulated and synchronized, so if the user switches back into the script's documentation tab, the documentation reflects any of the latest changes.
The problem with GDExtension is there is no way to register a ScriptEditor implementation. In our specific case, we don't need to expose this contract, but simply need a way that when our script UI detects the user changed the script contents, that we can trigger the EditorHelp to synchronize the script's documentation.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
There are likely several solutions, but two come to mind with varying degrees of impact.
The first would be to expose update_docs_from_script as outlined in https://github.com/godotengine/godot/pull/92916, which would allow any tool to request a resynchronization of a given script's documentation. The benefit of this change is that it's incredibly lightweight, can easily be backported, and solves our immediate concern.
Now the more long-term solution would be to expose ways to register ScriptEditor implementations with Godot. This would be a more intrusive change, and not one that would solve our immediate concern as it would force a complete rewrite of our UI bindings given that ScriptEditor isn't something that is currently usable in GDExtension for script implementors.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
It simply exposes a method to GDExtension.
In our code when we detect the user has saved our script instance, we can get the ScriptEditor from the EditorInterface and call the update_docs_from_script method by passing our script instance. This would synchronize the EditorHelp UI for the script's documentation if its open just like GDScript.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, currently the EditorHelp integration is tightly coupled with ScriptEditor and this contract is limited and not completely exposed to GDExtension for godot-cpp to actually implement a ScriptEditor implementation.
Is there a reason why this should be core and not an add-on in the asset library?
Because an addon cannot presently synchronize the script's help when it changes via any binding.
Describe the project you are working on
A scripting language extension for Godot using GDExtension.
Describe the problem or limitation you are having in your project
When a GDExtension plug-in implements the
ScriptExtension
andScriptLanguageExtension
contracts, part of these contracts allow the script to submit commented documentation that can be rendered in the editor's documentation panels, i.e.:The problem is that once the documentation has been generated and shown to the user in the editor, there is no way for a GDExtension-based solution to synchronize the documentation view. The user has to close the documentation tab and then research for the class and re-open the documentation for it to update.
In the engine's source, this synchronization is hidden behind the tight coupling of
ScriptEditor
andEditorHelp
. When a script is saved in theScriptEditor
, this automatically causes the documentation for the script to be repopulated and synchronized, so if the user switches back into the script's documentation tab, the documentation reflects any of the latest changes.The problem with GDExtension is there is no way to register a
ScriptEditor
implementation. In our specific case, we don't need to expose this contract, but simply need a way that when our script UI detects the user changed the script contents, that we can trigger theEditorHelp
to synchronize the script's documentation.Describe the feature / enhancement and how it helps to overcome the problem or limitation
There are likely several solutions, but two come to mind with varying degrees of impact.
The first would be to expose
update_docs_from_script
as outlined in https://github.com/godotengine/godot/pull/92916, which would allow any tool to request a resynchronization of a given script's documentation. The benefit of this change is that it's incredibly lightweight, can easily be backported, and solves our immediate concern.Now the more long-term solution would be to expose ways to register
ScriptEditor
implementations with Godot. This would be a more intrusive change, and not one that would solve our immediate concern as it would force a complete rewrite of our UI bindings given thatScriptEditor
isn't something that is currently usable in GDExtension for script implementors.Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
It simply exposes a method to GDExtension.
In our code when we detect the user has saved our script instance, we can get the
ScriptEditor
from theEditorInterface
and call theupdate_docs_from_script
method by passing our script instance. This would synchronize the EditorHelp UI for the script's documentation if its open just like GDScript.If this enhancement will not be used often, can it be worked around with a few lines of script?
No, currently the EditorHelp integration is tightly coupled with
ScriptEditor
and this contract is limited and not completely exposed to GDExtension for godot-cpp to actually implement aScriptEditor
implementation.Is there a reason why this should be core and not an add-on in the asset library?
Because an addon cannot presently synchronize the script's help when it changes via any binding.