Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clicking on a sub-resource closes the sub-inspector it is located in, instead of opening in a sub-inspector, if an EditorPlugin handles it #64700

Open
Zylann opened this issue Aug 21, 2022 · 2 comments

Comments

@Zylann
Copy link
Contributor

Zylann commented Aug 21, 2022

Godot version

f2a6168

System information

Windows 10 64 bits GLES3 GeForce GTX 1060 6GB/PCIe/SSE2

Issue description

I wanted to adjust some inspector UI in my module and got faced with a strange unexpected behavior.

I have the following properties in a custom node:

image

library is a resource, which contains sub-resources.
If I click on the sub-resource on the right of Item 1, it usually opens a nested sub-inspector. However, if I create an EditorPlugin which handles the class of that sub-resource, clicking that sub-resource instead closes the parent sub-inspector, leaving it in this state:

image

This happens even if the editor plugin does nothing, apart from returning true in handles for that class. There is no errors, so this is quite confusing.

There is a possible design issue that this highlights: if two sub-inspectors handled by the plugin are open, which one is "currently being edited"? If we only rely on the edit method, we could say the last opened one, but it could be confusing since multiple can be opened still. Or maybe considering the "currently edited" item is up to the plugin to decide how to handle, in which case relying on edit is the wrong approach.
If there are other reasons this cannot work, at least it could open as a full inspector instead.

Meanwhile, perhaps I can workaround this by not handling this object type, yet still registering an inspector plugin and somehow cache the passed object in parse_begin, so sub-inspectors can still work? Plugins are not "instanced" when one or more objects they handle are inspected, but custom controls added to their inspectors are.

Steps to reproduce

Have MyNode with a MyResource property. MyResource in turn contains a MySubResource property. Then have two editor plugins, one handling MyResource, and another handling MySubResource. They don't need to do anything particular, just return true when matching their associated class in the handles method.

Minimal reproduction project

The reproduction steps are quite specific so I wrote a reproduction module, which you can paste in the modules folder:
subinspector_plugin_issue.zip

Create a MyNode, then in the inspector of that node, create a new MyResource. Then inside the MyResource, create a new MySubResource. Observe clicking on MySubResource closes the MyResource inspector instead of opening a MySubResource inspector.


Note for more context, this is how the full inspector setup I'm making is (here using the workaround of not using handles):
image

@YuriSizov
Copy link
Contributor

This is a duplicate of #52779. At one point a proper solution was supposed to be #45085, but @reduz preferred to fix the plugins we have built-in and change their behavior to avoid these issues. Of course, this doesn't work for user plugins.

In 3.x this is mitigated by disabling sub-inspectors for sub-resources in such cases: #52984.

@Zylann
Copy link
Contributor Author

Zylann commented Aug 22, 2022

Right, in this present case I actually didn't need to use handles() since the functionality is confined to the inspector, there is no other particular editor popping up. I was just confused about the unexpected behavior and figured I'd write my thoughts about it. So technically I wasn't blocked yet, I hope it gets figured out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants