Custom settings support for plugins

[Murateba]

Describe the project you are working on

Add support for custom sections in plugin.cfg files #95866

Custom settings support for plugins under res://addons/

• Custom settings declared in plugin.cfg by plugin developer
• Those settings can be adjusted in Project Settings -> Plugins on the go
• Settings are divided into sections
• Values of settings are easily accessible for plugin's main script

Describe the problem or limitation you are having in your project

When developing plugins, I create custom sections in my plugin.cfg to help customize the functionality of plugin across different projects.

But there are two limitations that I'm facing:

Adjusting settings To change the value of a custom setting, project developer needs to edit plugin.cfg for that plugin manually (find the section -> find the key -> do the changes -> save -> reload) which is not handy.

Accessing settings To access these custom settings, developer needs to use ConfigFile and manually load plugin.cfg which is not handy again because of extra work such as excluding default [plugin] section when loading, finding the path of file, re-loading, etc.

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

This feature changes the way Plugins tab look in Project Settings window. Shows a drop-down menu for each custom section and includes keys that have a supported type of value.

Custom settings can be edited directly within the editor, removes the requirement of editing plugin.cfg file. Automatically reloads and updates, settings can be accesed with get_plugin_settings() in main script. No need to deal with ConfigFile anymore.

Indicates the type of setting (int, bool, String, Color, Vector2, etc...), changes the adjusting way if necessary.

Supported types

• String
• int
• float
• bool
• dictionary
• array
• Color
• Basis
• Vector2
• Vector3
• Vector4
• Vector2i
• Vector3i
• Vector4i
• AABB
• NodePath
• StringName
• Transform2D
• Transform3D
• Callable
• RID
• Rect2
• Rect2i
• Signal

Previews

[plugin]
name="Skibidi Plugin"
author="Murat"
description=""
version="1.0.0"
script="skibidi.gd"

[sodas]
coke=true
pepsi=false
monster=true
redbull=true

[sky]
sky_color=Color(135, 206, 235, 255)
heaven_gate_position=Vector2(123, 456)

[misc]
unicorns=["unicorn1", "unicorn2"]
ants={"ant1": {"name": "notsoant"}}
gravity=420

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

* * *
func init(api_key: String, features: Dictionary):
   data = {auth: {key: api_key}}
   response = make_request("example.org/api/v2", data)
   if(features["Database"]): activate_database()
   if(features["Auth"]: activate_auth()
   if(features["Telemetry"]: activate_telemetry()
* * *
project_settings = get_projects_settings()
app = init(project_settings["Keys"]["APIKey"], project_settings["Features"])
* * *

* * *
func _enter_tree():
   project_settings = get_projects_settings()
   if(project_settings["general"]["enable_dock"]:
      dock = load(project_settings["dock"]["scene"])
      add_dock(dock)
      dock.color = project_settings["dock"]["color"]
      dock.text = project_settings["dock"]["text* 
* * *

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

It would be very hard to implement this feature with a few lines of script.

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

This feature should be core because it directly effects add-ons and makes them easier to use. Users should easily interact with installed plugins in their projects by default, not by downloading another add-on from asset library. Making this feature core will likely to hype plugins.

[KoBeWi]

Project Settings are a better place for plugin settings. Some people use git submodules for their addons, or just don't like modifying addon content.

[passivestar]

I believe for project-independent settings you can use EditorSettings?

[HolonProduction]

I actually think we should streamline custom settings for addons, but we should do it in a way that reduces boilerplate to create custom project and editor settings. A lot of plugins already implement their settings in this way so this concept would create two competing systems.

Also it would make plugin updates impossible without erasing user settings.

The plugin.cfg is a static manifest for the plugin, user settings don't belong in there.