Open BanchouBoo opened 2 years ago
Would it be possible to declare and use custom annotations directly? i.e. writing:
@export @min_max_slider(0.5, 71.7) var var1: Vector2
It would make the syntax much cleaner, and possibly open up other use cases
Would it be possible to declare and use custom annotations directly? i.e. writing:
@export @min_max_slider(0.5, 71.7) var var1: Vector2
It would make the syntax much cleaner, and possibly open up other use cases
While this is nicer to read and write, it also presumably would require manually registering new annotations, which I feel would lessen the flexibility compared to being able to add any arbitrary string identifier for a custom annotation without registering it first, which also has the benefit (or, depending on context, detriment) of if some plugin that uses a custom gets removed, all your code that uses that annotation doesn't start throwing errors because the annotation is no longer registered, because it doesn't need to be to begin with.
Now, if we could have both that would certainly be ideal, because there are certainly instances where you would want an annotation to throw an error if you're trying to use it when nothing explicitly is set up to register support for it, but that won't always be the case.
While this is nicer to read and write, it also presumably would require manually registering new annotations, which I feel would lessen the flexibility compared to being able to add any arbitrary string identifier for a custom annotation without registering it first, which also has the benefit (or, depending on context, detriment) of if some plugin that uses a custom gets removed, all your code that uses that annotation doesn't start throwing errors because the annotation is no longer registered, because it doesn't need to be to begin with.
As far as I read the annotation proposals (the original ones) this can go away when we can finally have custom annotations.
Describe the project you are working on
No specific context, this could be applicable for any project.
Describe the problem or limitation you are having in your project
As it stands, if you want to make a custom inspector involves putting together a whole plugin and targetting specific node types and property names to place the inspector. This is great if you have a very specific tool you're putting together, but if you want a generic custom inspector that you can throw into any project onto any object and any variable, such as the below image from a Unity plugin, this isn't really a good option. The closest you can get is to have an
EditorInspectorPlugin
with acan_handle
function that always returns true, then use a naming convention for variables that want to use that particular inspector, using the example below that could be something like any Vector2 prefixed withminmax_
. This, however, is very awkward and not ideal.Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a new annotation for arbitrary custom data, e.g.
@custom
The annotation can take any number of arguments of arbitrary data, with the first argument being a required String name identifier for that particular annotation. A variable can contain any number of
@custom
annotations and those are passed to theparse_property
function forEditorInspectorPlugin
s as a dictionary, where the identifier is the key and the rest of the arguments are stored in an array as the value.This not only makes creating easily resuable custom inspectors much simpler, it also lets users add arbitrary data to a variable for whatever else they might think of.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Example for the previous MinMaxSlider Unity plugin:
script.gd
inspector_plugin.gd
and now you have a way to throw this inspector onto any Vector2 (or any other type you add support to for this particular inspector)
If this enhancement will not be used often, can it be worked around with a few lines of script?
As already stated, the closest work around is awkward to work with as it forces particular naming conventions to get specific inspectors (it also doesn't give you a way to pass arguments along to the custom inspector).
Is there a reason why this should be core and not an add-on in the asset library?
Having a universal standard for people to craft portable inspector plugins that people can throw into any project and use is very valuable.