You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project
Any "meta" EditorPlugin that relies on or tries to interact with other addons/plugins only has one way of "detecting" changes:
Connect to the EditorFileSystem.filesystem_changed signal & do a full recursive search manually. This works, but is silly because the Godot Editor already does this for us, it simply doesn't surface this in-memory data to developers when the scan completes.
So we have an expensive & frequently executed, recursive File I/O operation being triggered by the Godot Editor & however many "meta" EditorPlugins a project may care to install, but it's all perfectly avoidable.
Note: as an alternative, you can peek into the ProjectSettings data, but it only shows enabled plugins; nothing disabled, and no non-plugin addons are listed).
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a virtual _addons_changed method to the EditorPlugin class that gives developers a callback by which they can react to the changes in the addons & plugins detected by the Godot Editor. The API already collects this data every time the editor enters focus, a user changes a plugin's status, or even just when the user opens the list of plugins in the ProjectSettings; it just isn't being surfaced to developers fully.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
@toolclass_nameMyPluginextendsEditorPluginfunc_addons_changed(addons: Array[Dictionary]) ->void:
foraddoninaddons:
print(addon.plugin) # The `EditorPlugin` instance. May be null if the addon is not a plugin or if it is disabled.print(addon.config_path) # The path to `plugin.cfg` file. May be null if the addon is not a plugin.print(addon.name) # The name from the `plugin.cfg`. May be null if the addon is not a plugin.print(addon.is_enabled) # `true` if the addon is a plugin and is currently enabled.print(addon.dir_name) # the subdirectory where it resides at `res://addons/<dir_name>`, to differentiate non-plugins.
From there, developers have a lot more power to do whatever they want to do without having to redo the hard work that the editor just did.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It's about 40 lines of EditorPlugin script code, but it's also executed VERY frequently (every time the filesystem changes), and it's just redoing work that the editor has already done & is storing in memory.
Is there a reason why this should be core and not an add-on in the asset library?
Attempts at solving via addon/plugin have already been made, but are proving unsatisfactory, hence the proposal to expand their capability.
The text was updated successfully, but these errors were encountered:
willnationsdev
changed the title
Add a virtual EditorPlugin method that triggers when the status of any EditorPlugin changes.
Add a virtual EditorPlugin method callback that triggers when the status of any addon or EditorPlugin changes.
Dec 9, 2024
Calinou
changed the title
Add a virtual EditorPlugin method callback that triggers when the status of any addon or EditorPlugin changes.
Add a virtual EditorPlugin method callback that triggers when the status of any addon or EditorPlugin changes
Dec 9, 2024
Describe the project you are working on
The Godot Plugin Refresher plugin.
Describe the problem or limitation you are having in your project
Any "meta" EditorPlugin that relies on or tries to interact with other addons/plugins only has one way of "detecting" changes:
Connect to the
EditorFileSystem.filesystem_changed
signal & do a full recursive search manually. This works, but is silly because the Godot Editor already does this for us, it simply doesn't surface this in-memory data to developers when the scan completes.So we have an expensive & frequently executed, recursive File I/O operation being triggered by the Godot Editor & however many "meta" EditorPlugins a project may care to install, but it's all perfectly avoidable.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a virtual
_addons_changed
method to theEditorPlugin
class that gives developers a callback by which they can react to the changes in the addons & plugins detected by the Godot Editor. The API already collects this data every time the editor enters focus, a user changes a plugin's status, or even just when the user opens the list of plugins in the ProjectSettings; it just isn't being surfaced to developers fully.Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
From there, developers have a lot more power to do whatever they want to do without having to redo the hard work that the editor just did.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It's about 40 lines of EditorPlugin script code, but it's also executed VERY frequently (every time the filesystem changes), and it's just redoing work that the editor has already done & is storing in memory.
Is there a reason why this should be core and not an add-on in the asset library?
Attempts at solving via addon/plugin have already been made, but are proving unsatisfactory, hence the proposal to expand their capability.
The text was updated successfully, but these errors were encountered: