Simplify the layout of nested resources in inspector

[passivestar]

Describe the project you are working on

Any project

Describe the problem or limitation you are having in your project

Inspector's layout makes it hard to work with nested resources. The reorder, delete and add element buttons take big amount of space and it only becomes worse with each new level of nesting. While it's possible to open nested resources separately and use history navigation to go between the main and nested resources, it's often more convenient to do quick edits straight from the main resource so a layout that doesn't waste so much space would help a lot

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Move the "Reorder" and "Delete" buttons to the header. Move the size input to the bottom and put it on the same line as the "Add Element" button

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Before	After

---

Changelog

| Before | Iteration 1 | Iteration 2 | Iteration 3 | Iteration 4 | |--------|--------|--------|--------|--------| |  |  |  |  |  |

**Edit**: A few people on twitter pointed out that it's easy to accidentally revert the array instead of adding an element to it because of how close the buttons are, and I agree. It will be better to put that button to the right of the dropdown where the remove button currently is in the mockup **Edit 2**: Made a mockup of a version without the Size field and attached it as "Iteration 2". After some conversation this seems to be a good idea because the Size input might not be used often enough to justify every array eating a line for this input. This version would add 2 new buttons to the dropdown menu - "Clear Contents" that would be the same as setting the size to `0` but faster because you won't need to type it in, and "Set Size" that would allow you to set the size via a popup in case you need to trim the array to an exact size or for other rare use-cases. For reference types you'd usually drop multiple items onto the field, and primitives types should be covered by a QOL that allows you to quickly add a new element by pressing Enter when you're done typing in the value for the last array item The second iteration also moves the add button to the right so that you don't accidentally revert **Edit 3**: I collaborated with @GuyUnger, he improved the design even further by fixing spacing and switching to glyph-only buttons. His version is what you currently see in the "After". I'm a big fan of this design, it looks great and it will have an immense impact on editor usability as you'll be able to see more data and navigate through it easier **Edit 4**: Small fix - aligned the left sides of the dropdowns and input fields in the middle just like those are aligned in the current version of godot **Edit 5**: Attached the version that has size and add buttons in the arrays to address usability concerns. Notice that instead of "Size:" it now says "[Property] Size:" so that you always know what array you're adding to no matter how far you scrolled or how deep you nested

---

Edit 6: Considering all the feedback it seems like keeping the add button on the bottom and keeping the size input is the way to go. It's intuitive and it's the easiest to implement as it won't need any additional changes like context menu buttons. And since we're combining the size input with the add button we're still saving a row of space which is great. My problem with not always knowing what I'm adding to (when there's a lot of nesting) is addressed by the size property including the name of the array/dictionary property (i.e "Footstep Sounds Size")

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't think so

Is there a reason why this should be core and not an add-on in the asset library?

Editor usability

[theraot]

I like the way it looks, and I like that saves some space... But how would it look with deeper nesting?

[AdriaandeJongh]

I also made a todo for myself to make a proposal for this so I'm glad to see this!

Seeing the great mockup you made, i wonder whether it isn't more logical to place the add element button alongside the size property? I'm of the opinion that the size field doesn't have to be a full width item and it could probably be on the same line as an add element button.

But perhaps more strongly do i feel that the size property should be positioned at the end of the array items, next to where the add element button is in the current design. After all, when adding elements and making adjustments to elements one by one, it's the end of the list where you realize you need more elements. I do think the current design got that UX right.

[passivestar]

I like the way it looks, and I like that saves some space... But how would it look with deeper nesting?

This will need a prototype to test properly with lots of nesting and figure out all the details (I drew the mockup in a photo editor), but buttons in the header at least seem to make sense because i.e the add element button is right near the property name so you'll always know exactly what array you're adding to

Seeing the great mockup you made, i wonder whether it isn't more logical to place the add element button alongside the size property?

Maybe, but somebody asked on twitter if the size input is necessary at all when there are add and delete buttons, and honestly I'm not sure, I personally never use the size input. Maybe it's possible that you'll be able to hide the size input via editor settings to save more space?

But perhaps more strongly do i feel that the size property should be positioned at the end of the array items, next to where the add element button is in the current design. After all, when adding elements and making adjustments to elements one by one, it's the end of the list where you realize you need more elements. I do think the current design got that UX right.

I see your point. One small advantage of the add button on top is you can mash it multiple times to add multiple items and the button won't move, it might be more convenient than to aim at the button after every click or to enter the array size with keyboard

I think it makes sense logically for the add button to be on the bottom for simple lists, but when you have a lot of nesting it's starting to get confusing because you only have the last few properties to determine the data type in that array, and often you need to scroll way up to the header anyway (at least my experience)

For arrays of simple types (strings, floats, etc) perhaps we could add a little QOL where when you press enter after you're done editing the last element of the array it would add a new element (and to unfocus without adding you'd press escape)

[plyoung]

Could save more space by replacing the "Array[string]..." field with the size field. Do not see point of knowing the type. The add button could then be at the back of this field so align with where the removal buttons are.

[DigitallyTailored]

I love this! I think having the plus on the right of the Array[string] away from the reset button would be better ux - save misclicking and resetting everything - plus it's right beside the size that way.

[GuyUnger]

im not sure about extending the top to cover the size but it kind of makes sense, its not just a property its holding and making it part of the header makes the items inside it a clearer list. i definitely think the 'add' icon fits better here, just above the delete buttons that counter its action, and next to the size it will increase

[passivestar]

After some discussion me and @GuyUnger made some changes that take usability and aesthetical points into consideration, the attached post has been updated with the latest version, courtesy of @GuyUnger ✨

[AdriaandeJongh]

I'm a fan of the design: it's clearer for sure. But I'm still not sure about how to address the point I made earlier – that I regularly find out at the end of a list that I need another element. I can't imagine I'm the only one with that experience.

Perhaps this ux problem in the new UI could be remedied by RMB click on any element and have 'insert new element above / below'? Or perhaps there can also be a smaller + button at the end of the list?

[passivestar]

Perhaps this ux problem in the new UI could be remedied by RMB click on any element and have 'insert new element above / below'?

Oooh, that might be a good idea! Could also additionally add a hotkey for insert below, so that you don't need to RMB

[NatCracken]

Having the add button at the end is really useful. Once a list gets long it'll be a real pain to have to keep going to the top of the list every single time you want to add a new element. Double or triple this for custom resource types. Don't know how other people do it, but I like to have most of my handcrafted game data in list of custom resources either in scene or in "resource container" resources in the filetree. These resource lists can get (physically in the window) very long since they correctly nest in the list. But since the add button is at the bottom I can just add a new one, set its values, add a new one, ect... until I have the numbers for every enemy or item or whatever made and ready to use.

On a less important note, having the add button also reserves space on the ui for the inputs required for more complicated add operations like adding a unique key or enum to a hashed collection or anything with dictionaries. People always talk about wanting that but nothing ever comes of it so like don't put too much weight in it... but it is a nugget to think on. I dunno if they would inherit from the list style or if they would have their own inspector made.

[Dark-Horizons]

Thank you passivestar for this valuable suggestion. My suggestion would be to put some space between the frames indicating the sources and thicken the frame a little. I have attached a study about this. The reason for this is that the existing elements look too nested. This makes it difficult to read.

[GuyUnger]

with add button back at the bottom

im not sure if the size property is needed but if the add button will take up a line anyway they could be combined. and passivestar had the idea to include the variable name in the size text so when a list is long it can be helpful to show which list it is at the bottom too:

[passivestar]

Guy's mockup but if section dropdowns used section colors + waveform w/ transparency:

im not sure if the size property is needed but if the add button will take up a line anyway they could be combined

I think size should stay if the button stays, there's no reason for it not to

My suggestion would be to put some space between the frames

this should be tied into the editor spacing calculation that's configurable through editor settings (if it isn't already). I don't think the existing value needs change, the existing inspector layout already makes it hard to fit data on screen

[univeous]

(This might be slightly different from the issue being discussed in this proposal, but I believe they are closely related)

I find the current functionality of the "Add Element" button somewhat cumbersome. When working with resources, the current workflow involves several steps: clicking the button to add an empty element, clicking the empty element, selecting the resource type, and finally clicking the newly created resource to expand it. This requires four clicks to create and edit a resource, which is particularly annoying when handling a large number of resources.

I suggest that clicking the "Add Element" button should immediately bring up the resource type selection. If the array corresponds to only one type of element, it should even create a new element with default values directly.To maintain the ability to add an empty element, we could implement a fallback option, such as middle-clicking or right-clicking the "Add Element" button.( But if we can quickly create and load resources, does adding an empty element really make sense?)

Additionally, adding existing resources to an exported array in inspector is not very convenient either. Currently, we need to click "Add Element" and then drag the resource onto the new empty element. It would be much more efficient if dragging a resource onto the "Add Element" button automatically appended it.

[CptFubar]

I really like this proposal to improve the inspector for several reasons, adding to the conversation i like to add further ideas of improvement. The added preview is trying to merge several suggestions already provided by @Dark-Horizons "thicker frames" and @GuyUnger "better iconography" with the add buttons. This design is trying to take advantage of horizontal space that is wasted on index values (irrelevant information in most cases) and offering to organize information in a better column structure. I also avoided to place any "add" buttons next to the "trash" icon to avoid the fat finger syndrome (touch interfaces) or an eventual miss click with the mouse. The thicker frames on the left side should be fairly visible (even with a similar color choice) for the tree structure at the cost of leaving the frame on the right side flush on the border.

[Rawalanche]

Guy's mockup but if section dropdowns used section colors + waveform w/ transparency:

I saw a twitter post and ran here to suggest that the panel header buttons should be just darker color of the panel header color instead of the same base UI color, and you've already beat me to it! 🥳

[Wolve-3DTech]

I agree with @univeous. I'm currently making a game with resources, in which i've got plenty of arrays. It's very tedious to click so many times to navigate in highly nested resources. I also totally agree with @CptFubar proposal.

[Wolve-3DTech]

I also love the UX proposal by @Dark-Horizons :).

[Wolve-3DTech]

I know it is not the place for, but i want to thank @passivestar for its amazing Godot UI theme. Thanks to it, my whole game dev experience has completely changed !

[Calinou]

@Wolve-3DTech In the future, please use the Edit button (located behind the … icon in the top-right corner of your comments) instead of multi-posting.

[Wolve-3DTech]

Thank you for the tip. I didn't know i could do that (I have not spent a lot of time on Github)

[groud]

While I like the desgin, technically, it adds some complexity to the interface which has to be considered.

The button in this new design needs to be provided by the first PropertyEditor, as it lies within its boundaries. That means additional code needs to be added by anyone who will want to implement their own PropertyEditor. Probably something to get/set the "button handle", and, if we want this to be optional, something like bool PropertyEditor::is_providing_array_handle(). That might revert to the previous state.

I mention we might want this to be optional because we have also cases like this, where multiple properties belong to the same array index: I know TileMap is deprecated, but we have other situations with this issue. Here the first element could provide the array handle, but that means all other properties' names won't be aligned with the first one anymore.