Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add a virtual EditorPlugin method callback that triggers when the status of any addon or EditorPlugin changes #11323

Open
willnationsdev opened this issue Dec 9, 2024 · 0 comments

Comments

@willnationsdev
Copy link
Contributor

willnationsdev commented 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.

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

@tool
class_name MyPlugin
extends EditorPlugin

func _addons_changed(addons: Array[Dictionary]) -> void:
    for addon in addons:
        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.

@willnationsdev 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 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants