You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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):
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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 anEditorPlugin
whichhandles
the class of that sub-resource, clicking that sub-resource instead closes the parent sub-inspector, leaving it in this state:This happens even if the editor plugin does nothing, apart from returning
true
inhandles
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 onedit
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
inparse_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 aMyResource
property.MyResource
in turn contains aMySubResource
property. Then have two editor plugins, one handlingMyResource
, and another handlingMySubResource
. They don't need to do anything particular, just returntrue
when matching their associated class in thehandles
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 newMyResource
. Then inside theMyResource
, create a newMySubResource
. Observe clicking onMySubResource
closes theMyResource
inspector instead of opening aMySubResource
inspector.Note for more context, this is how the full inspector setup I'm making is (here using the workaround of not using

handles
):The text was updated successfully, but these errors were encountered: