Open Gnumaru opened 3 weeks ago
AThousandShips
commented
3 weeks ago So to clarify this would mean just read only display the data? This would still be a relatively large change as the editor doesn't allow this kind of dynamic display, but it could still be done, but I'm not convinced it's worth the effort for this specific use case, it'd be more relevant if there were other use cases for this type of display
Gnumaru
commented
3 weeks ago Yes. Just read-only display of the data. I'm not familiar with the codebase so I'm unable to tell if this would be a trivial or a massive change. I'm just supposing that completely implementing export of untyped variables in gdscript by users would be a much bigger effort than just specifically displaying the json resource data property, but this is just a guess, maybe the difference in effort of both things are small.
When I use the JSON resource to store my data, it works as expected when saving and loading, but the inspector is unable to show the data
But if I use a wrapper script that wraps the data inside a single element array, I'm able to see the data as expected.
If I was viewing a real json file this would not be a problem since I can just open the file itself and view it's contents. But this is not json, it is a yaml file (but it could be anything, like an sqlite database) and I use json only as a wrapper, only to avoid using a wrapper script in order to save any kind of untyped data. Since my import script is saving the result as a tres file (instead of res) I'm able to search and open it in the .godot/imported directory and view it's contents
My import script also create temporary json files alongside the original files, so I can just keep them and use them for visualizing the data.
As you can see, for my personal use case I do have workarounds. I don't have a real blocking problem, just a little annoyance. I even said in the original message that this might be achievable creating an addon since I have already seen a couple of addons in the asset library that change the behavior of the inspector, like custom dictionary inspectors for example.
But my original hunch was that, since the inspector can already inspect the contents of arrays and dictionaries, which are untyped and can only be dynamically evaluated, this same logic could be applied to untyped properties, as I have said in the original message:
The inspector could have a fallback case where, if the exported type is just Variant, It will look at the actual property value in order to determine how to draw the inspector. If the value is a float, it will draw a float field. If it is a dictionary, it will draw a dictionary field.
Just like currently happens for array and dictionary items.
Describe the project you are working on
More than one godot project.
Describe the problem or limitation you are having in your project
I'm using the JSON resource as a generic wrapper for storing any variant data created by other means than importing a json file. The native JSON resource has an exported "data" property which is untyped. Since godot normally does not allows exporting untyped data, the data property shows up in the editor as "null" instead of exhibiting the property contents. It does show the revert icon when the value is different from null, so you know when the property is null or not null, but when it is not null it is not possible to know what it is without opening the json file itself. But I'm using the JSON resource to save miscelaneous data that did not come from json, so there is no json file to look at.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
I am not proposing to allow exporting of untyped variants, which would be great but is a change of larger scope. I'm proposing that the inspector shows the correct data content, whatever it is, which is a change of smaller scope. This way I can create import plugins that save miscelaneous data as json and I can inspect the data content instead of opening the imported tres file inside .godot/imported/
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I'm not familiar with the editor source code. I assume that the inspector uses the declared exported property type to know how to draw the inspector. The inspector could have a fallback case where, if the exported type is just Variant, It will look at the actual property value in order to determine how to draw the inspector. If the value is a float, it will draw a float field. If it is a dictionary, it will draw a dictionary field. I assume that this dynamic behavior already exists for array and dictionary items since it is possible to have untyped arrays where every item is of a different type and the editor draws the correct widget for each value.
If this enhancement will not be used often, can it be worked around with a few lines of script?
I suppose it is possible. I have already seen addons that change the inspector, so I assume it is perfectly possible to create an addon for that.
Is there a reason why this should be core and not an add-on in the asset library?
JSON Resource is a native type, and it is a great way of wrapping miscellaneous data in a resource for storage. Using it in extensions and addons allow having only a single wrapper type instead of creating wrapper scripts exporting arrays just for the sake of storing untyped data. I personally think having it on core would be of great value for those that create addons.
Last consideration
As a last note, I have created a feature proposal instead of a bug report because I think the current behavior is intentional. I think not being able to export untyped properties is intentional (at least for the time being), and when the JSON resource was created the problem arose that it did just that, export an untyped property. So I assume that, at the time, the workaround was to create a null field for any exported untyped property.