Provide unified access to plugin settings

me2beats commented 3 years ago

Describe the project you are working on

Godot Editor plugins (GDScript)

Describe the problem or limitation you are having in your project

There are plugins that do not require UI (controls, docks, toolbars, etc.) to work, since they can perform main actions immediately when the plugin is activated. However, such plugins may still want to have a plugin settings window for the user. And in this case, finding a window with settings can be a non-trivial task for the user, sometimes it may require viewing the source code, or reading/writing plugin docs, etc. Also the problem is that after getting used to one way of accessing the plugin settings, the user will find other ways unintuitive (which will be provided by other plugin developers).

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Providing unified access to plugin settings could solve the problem.

By that I mean:

for the plugin user: there might be a default, preferred way to open the settings window of any plugin (but this doesn't mean any plugin should have settings controls).
for the plugin developer: there might be a way to specify the (settings) control to open when the settings window is opened.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

We could use the EditorPluginSettings window as a window for accessing plugin settings.

plugin-editor

The list of plugins is a Tree control, so we could add a new column with the title Settings: and display buttons (gear icon) in it, clicking on which would open a window with settings. Such buttons could only be added for those plugins that explicitly indicate the settings window or how to access them.

That is, as you can see, plugin x has settings window.

How the developer could specify ("register") a plugin settings window?

EditorPlugin class could have virtual method _get_settings_control()

The plugin developer could override this method like this:

_get_settings_control ():
    return settings_control

where settings_control could be any PopupMenu (with settings of course) or just a control that would be opened when user clicks on the gear icon (see image).

Additionally, there could be a more flexible virtual method _get_settings(), which would contain a sequence of actions that would open the settings window (in case this is a custom [not Popup] settings window or this window is already in some dock/tab, etc.).

Thus, we would get a unified and intuitive way to access any the settings window.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Any workaround would be ugly or have drawbacks imo

Is there a reason why this should be core and not an add-on in the asset library?

Implementing this as an addon makes it much less useful and definitely not a unified solution.

Jummit commented 3 years ago

Just a thought: there is also the possibility of putting plugin related settings in the appropriate Project/Editorsettings sections. I don't know if that's better or worse organization.

YuriSizov commented 3 years ago

Just a thought: there is also the possibility of putting plugin related settings in the appropriate Project/Editorsettings sections. I don't know if that's better or worse organization.

This could also benefit from consolidation and more straight forward API. I don't think those two ideas are contradicting each other. There can be a button on the plugin screen that opens the editor/project settings section.

Though the way settings dialog works is very limited and is made more with automation in mind. Ideally even there I would expect an ability to completely define your own form for your plugin.

me2beats commented 3 years ago

Just a thought: there is also the possibility of putting plugin related settings in the appropriate Project/Editorsettings sections. I don't know if that's better or worse organization.

In my understanding, Editor Settings are kind of cross-project settings, which I assume should work the same in any project. For example, if you set up shortcuts in EditorSettings, they will work the same in another project. Therefore, I'm not sure that it makes sense to somehow use EditorSettings in this case.

YuriSizov commented 3 years ago

Jummit mentioned both ProjectSettings and EditorSettings, though 🙂 Depending on a plugin, it may use any of them, or both.

Jummit commented 3 years ago

For example an editor-only todo-list plugin could add a global editor setting to change the colors. They would exist in every project as they are global, but only be used if the plugin is enabled.

Two more things:

Would each plugin have it's own section, or could plugins use existing sections? I'm for one section per plugin, because that's the easiest to implement and use.

And what happens if the plugin is disabled? Do the settings get lost, or are they kept until the user deletes them manually?

KoBeWi commented 3 years ago

You can use ProjectSettings to store any plugin data. I store data from my plugins under addons/pluginname. There's no convention, but you can just mention it in the description and it's easy to find. The downside is that it's not really customizable (just default type-based inspector controls).

godotengine / godot-proposals