Make grouping exported variables easier

[Zireael07]

Describe the project you are working on:
2d space game

Describe the problem or limitation you are having in your project:
My nodes (e.g. planets, stars) have a LOT of exported variables, often thematically grouped (eg. physical properties and cosmetic stuff, ship physics and AI stuff and cargo...)

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
We already have a workaround to group the exported variables, https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_exports.html#adding-script-categories , but it is... NOT pleasant to use.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
The syntax proposed in PR #40669 is the following: cosmetic (section, "sectionname"): followed by an indent and any variable declarations wanted.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It can be worked around, but it takes TOO many lines of script (circa 10 per each variable, times 10 variables, that's around 100 lines just for that - and in another project, I have nodes with 20 variables...)

Is there a reason why this should be core and not an add-on in the asset library?:
I don't think addons can do such deep injections into the inspector, AND the same NEEDS to apply to remote scene tree debugging, where the issue is exacerbated by also showing non-exposed variables.

[groud]

Make grouping related variables easier.

Sorry, but this is not a description of the feature or how it would be implemented... Could you at least copy-paste the syntax proposed in the PR related to this proposal. This is the thing that should be discussed, not "making something easier", which isn't really a proposal...

[Zireael07]

Whoops, it was fairly late and I didn't notice I put it in the wrong place :P - updated.

[golddotasksquestions]

Direct Link to the PR: godotengine/godot#40669

[Calinou]

Now that we have GDScript annotations, I suppose we could have a @category("Category Name") annotation. Here's what would happen:

• Properties would be grouped automatically with categories of the same name.
• The annotation must be added to every exported property to be added in a category, so that changing the declaration order can't break things. This is different to the C++ implementation, but I think it's more explicit this way.
• A single boolean property per category can have a @category_toggle("Category Name") annotation. When the property is false, hide all properties within the category except the toggle property itself.
  • A C++ equivalent of this would be the SpatialMaterial inspector where categories will be hidden or shown depending on the enabled features.
  • If there is more than one, print a GDScript parse error.
  • If this is used on a property that's not a bool, print a GDScript parse error.
• If only a single property is added to a category, print a GDScript warning as this is considered bad practice. People will have to unfold the inspector only to see a single property. Spare people's mice 🙂

Why not a generic programmatic API or a more complex syntax? See my comment here: #2080 (comment)
I think it's also likely to reproduce the usability quirks of _get_property_list() in one way or another.

[YuriSizov]

For posterity, vnen's proposal regarding grouping annotations was:

@export_category("category")
@export_group("group", "prefix") # All variables with name starting with "prefix" are added to the group.

[fire-forge]

This is a great idea! It would really help in cases like this where there's lot of properties that have the same prefix. If all of the tile_* properties could be in a group, that would make it a lot cleaner.

@export_category("category")
@export_group("group", "prefix") # All variables with name starting with "prefix" are added to the group.

An @export_subgroup("subgroup", "prefix") annotation for exporting subgroups would be a nice addition as well, but definitely not as important as a group annotation is.