Enable QuickOpen to see scripted resources

[willnationsdev]

Updates EditorQuickOpen so that resources with global script classes attached to them are properly recognized and handled.

Related Issues:

• Add first-class custom resource support godot-proposals#18

Related PRs:

• Allow exporting custom resources from/to GDScript, VisualScript, C#, and PluginScript. #48201
  • implements the Editor / Inspector tooling (specifically, the QuickLoad option in EditorResourcePicker)
• Fix custom resource icons not appearing in file system #60606 (dependency)
  • builds on top of a squashed version of this PR's commits. Once it is merged, I can rebase so that @Atlinx's commit(s) won't be present in my PR.
    Without this, teaching EditorQuickOpen to display applicable resource files would be prohibitively expensive since every file with the same native base type would need to be fully loaded just to check 1) if it has a script attached, 2) whether the script is a global class, and 3) whether the script class matches the exported property's type constraints.

Sibling PRs:

• Add GDScript resource export. #62411
• Script-class-aware Inspector & related controls. #62413
• Add C# resource export. #63126

Considerations:

• None.

[reduz]

This looks good to me, again I think we need to clean up the EditorData usage for these things, but it can be moved as a 4.1 task at this point.

[YuriSizov]

So my question is, why there are so many core changes required for this when #62413 improves the resource picker with relatively few inner adjustments? #62413 makes drag'n'drop from the filesystem dock work for all resources, which is about the same amount of checking as EditorQuickOpen needs. So why is all this needed?

Edit: Ah, I see. It depends on #60606 changes for some things. But I don't believe this PR actively needs anything from it more than #62413 does, right? I think we should strip this one to be more like #62413, then we can consider and review #60606 and its more fundamental changes.

After that both EditorQuickOpen and EditorResourcePicker can be updated to use the filesystem cache. Just leave a TODO note like you did for the resource picker for now.

Edit 2: Regarding your OG note:

Without this, teaching EditorQuickOpen to display applicable resource files would be prohibitively expensive since every file with the same native base type would need to be fully loaded just to check 1) if it has a script attached, 2) whether the script is a global class, and 3) whether the script class matches the exported property's type constraints.

How slow does it get in practice? We already have similar issue in other places of the UI, like the Create Node/Resource dialog. But I guess here it is magnified by the number of resources compared to the number of scripts defining classes, which would be significantly larger. Worst case, we can implement this and disable until we fix the performance with cache.

Because we'd love to merge this, but the core stuff seems problematic and in need of way more polish. We assume your own part is significantly smaller and clearer here.

[willnationsdev]

@YuriSizov I went ahead and added a bool property to toggle it for now, and it just goes ahead and loads the resources. If it ends up being too much of a performance issue, then we can just turn it off, as you mentioned, until a proper solution to caching can be implemented.

[akien-mga]

Looks good 👍

[akien-mga]

Thanks!

[KoBeWi]

What did this PR actually change? I could see custom resources in quick open before that and the custom icons are still not displayed.

[willnationsdev]

@KoBeWi Oh, huh. I didn't really quite get the chance to test it again after I stripped out the base stuff that Atlinx had contributed. It was supposed to ensure that resources with scripted type names actually show up in the resource list inside the QuickOpen dialogue, and that their custom icon would be displayed. Not sure why that wouldn't have worked since it was working earlier, and the only thing Atlinx's code should have contributed would've been caching the class info in the EditorFileSystem and me retrieving the data from there (which was changed to me just loading the resource directly).

[KoBeWi]

You mean the quick open that shows when you press Shift+Alt+O (default)? Custom resources have always appeared in there. It works even in 3.5.

But yeah, the icons don't show up. And this PR didn't fix that xd

[willnationsdev]

@KoBeWi No, that's something else entirely. If you export a scripted resource type, and then attempt to use the quickload option in the Inspector dropdown to populate the exported property, (where the QuickOpen dialogue is configured to have a base type associated with the user-defined class name), then the list of displayed resources would not previously respect that constraint. That is what was fixed by this PR. I wasn't aware of other issues because that's the only use case I was really experimenting with when I was implementing the other features. I can't recall actually setting up the icon bit though in my test cases, so never really confirmed that the icon was showing up. In short, if you fix the other bug that makes the icon not show up, then the fixed version will properly display the base global script class's icon if the QuickOpen dialogue is configured to use that global script class (which it wouldn't have done before).

[KoBeWi]

Makes sense. Though I tested it and I get empty dialog for some reason.

godot.windows.tools.x86_64_p2VkPKKmzE.mp4

It should show the TestTest.tres file, no?

[KoBeWi]

btw

If it ends up being too much of a performance issue, then we can just turn it off, as you mentioned, until a proper solution to caching can be implemented.

Yep, this should be disabled for now. Here's me trying to "quick" open a script:

godot_ohUkBeJcjW.mp4