Persistent additional data in plugin configuration files

[IceflowRE]

Describe the project you are working on

The initial purpose was to add additional data to the plugin.cfg which is handled by other plugins. For example dependencies or the compatible Godot Versions.
Currently this is erased when editing the plugin configuration with the editor.

Describe the problem or limitation you are having in your project

Currently if you want to update your plugin.cfg via the internal editor, it will only save the information based on the dialog.

editor/plugin_config_dialog.cpp

Which leads to overriding existing data.

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

A better way would be to just update the given values and that existing values persist.

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

I discovered two way of doing this:

1. on confirmation, load the config file, update the values, save the file.
   Problem here is, that the file is loaded twice. First on the initial load to display it and then again on saving.

2. Load the config file only once (or create an empty one if no file exists) and save as a member, then edit the values on confirmation and save it.

As iam not confident working with the Godot source code, i do not know which would be the Godot way to go. If you tell me which way (or another) the better one is, i could try to implement it.

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

No.

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

This will improve the plugin handling and saving additional configuration values.

[Calinou]

• Related to Add dependency handling and enable users to organize and publish addons and addon-collections as packages #142 and Add a way to specify compatible Godot versions for editor plugins #1613.

I think this makes sense in principle. That said, we may want to require custom properties to be written to a meta dictionary to avoid conflicts with future built-in fields.

That said, if you need the information you've described in the proposal, it's likely something that other plugins will need to define too – not just yours.

As a result, plugins should definitely be able to store a supported version range in plugin.cfg (likely as a semver string), so you can get an error if the add-on is unsupported for your current version.

Dependencies will be harder to get working though, we don't have a "slug" field that would define a unique plugin name.¹ This could be added too, likely in the plugin_author/plugin_name format, similar to PHP's Composer.

Footnotes

1. We shouldn't rely on the directory structure, as it may change with future add-on versions. Also, if you require the use of a specific fork for a plugin, it should be stated explicitly in the dependency statement (by having a different plugin_author part in the slug). ↩