It might be good to have another Editor Setting to keep the size row at the top,

What we could do is keep displaying the size at the bottom, unless the array has enough items to warrant displaying it both at the top and bottom.¹ This would be the case for any array with more than 1 page (20 items by default IIRC). This way, you can adjust the array's size regardless of whether you're at the top or bottom when it matters most.

Also, I suggest displaying the name of the array in the Size property as the proposal mentioned (e.g. Surface Names Size). This should make nested arrays easier to work with.

It might be good to have another Editor Setting to keep the size row at the top,

What we could do is keep displaying the size at the bottom, unless the array has enough items to warrant displaying it both at the top and bottom.[^1] This would be the case for any array with more than 1 page (20 items by default IIRC). This way, you can adjust the array's size regardless of whether you're at the top or bottom when it matters most.

That makes a lot of sense. Though I wonder if it's ever a concern if you can see both the top and bottom, if the user has a really low number of items per page set

Also, I suggest displaying the name of the array in the Size property as the proposal mentioned (e.g. Surface Names Size). This should make nested arrays easier to work with.

Oh I didn't notice that, thanks 😅

If the size property is not at the top, it will result in a significant degradation of the user experience - the size field will constantly change its position as the size is changed.

If the size property is not at the top, it will result in a significant degradation of the user experience - the size field will constantly change its position as the size is changed.

I can make it a setting, with options "top", "bottom", and maybe "split" for keeping the old layout.

Ok I think I found a good middle ground:

The add button is at the top next to the array button, and the size modifier is at the bottom. So from both the top and bottom you can add new elements easily.

This is how it looks in an array of arrays. The add button is hidden when folded:

I already added the editor setting for top vs bottom size controls, but I should probably remove it if this fixes all the same problems.

I can make it a setting, with options "top", "bottom", and maybe "split" for keeping the old layout.

Some thoughts about UX:

1. When you change the array size (increase or decrease), you want the position of the size field to always be in the same place.

2. When you want to add a new element to the bottom of an array, moving to the top (to click "Add element" button) and back to the bottom is counter-productive.

3. Having the "Add element" button on the same line as the size field is useless, because the size field button already has an up arrow that does exactly the same thing (adds an element).

@arkology what do you think of the design in the comment above. The add button always stays beside the array header, while the size controls stay at the bottom

Edit: The only downside I see is that you can't keep removing elements in place. 1, I'm not sure if that's really that big a deal, but 2, we can add a - button up there as well if it is

@dugramen
This will break (1) and partially (2) (up/down arrows are quiet small compared to current big "Add element" button - dont forget about tablet users with touchscreen) from #103257 (comment) at the same time.

When you change the array size (increase or decrease), you want the position of the size field to always be in the same place

There's no need to aim at the small button in the size field to remove elements when you can be clicking any of the trashcans in the list itself, they are bigger and you dont need to move your mouse between elements to remove multiple if you just start deleting from the middle of the list

For adding it's still better to provide bigger buttons to make sure it's usable on touchscreens. Size field is there to allow typing values in and displaying the size. One-by-one add/delete should be doable with normal buttons

What we could do is keep displaying the size at the bottom, unless the array has enough items to warrant displaying it both at the top and bottom. This would be the case for any array with more than 1 page (20 items by default IIRC).

You'd normally want to add elements to a paginated list from the last page of it, and the last page will have less than 20 items. And items aren't necessarily one-liners, you can have 3 nested resources that won't fit on screen. I like the idea of the second add button on the bottom but it should be based not on the number of items but rather on what the user can see on screen. Ideally you'd check if the header is scrolled out of view to show the bottom button

Renamed the setting to "embedded_list_buttons"

I'm not sure there's a need for a minor style change like that to be configurable, godot is already using that style of simple icon buttons in different lists extensively. Inspector arrays have heavy UI that benefits from them

This doesn't change the Array / Resource button design, which passivestar's design does

That doesn't necessarily need to happen in this PR, can always be done later

This doesn't affect dictionaries

Would be awesome to see, but can probably be a separate PR as well

There's no need to aim at the small button in the size field to remove elements when you can be clicking any of the trashcans in the list itself, they are bigger and you dont need to move your mouse between elements to remove multiple if you just start deleting from the middle of the list

Yeah that works well, but it's also worth mentioning untyped arrays are a bit different. The remove button is inside the type picker dropdown. Maybe we could add a dedicated delete button besides it? If that takes too much space, maybe we can move the type picker to the left side (next to the move handle or by the reset button)? Just an idea

Renamed the setting to "embedded_list_buttons"

I'm not sure there's a need for a minor style change like that to be configurable, godot is already using that style of simple icon buttons in different lists extensively. Inspector arrays have heavy UI that benefits from them

This setting disables the condensed design. I only added it because in some cases, like direct arrays of arrays of arrays, the condensed design could be less clear. I'm fine removing it though, since it may not be very common. Here's a comparison:

Embedded	Normal

This doesn't affect dictionaries

Would be awesome to see, but can probably be a separate PR as well

I actually wanted to do it to dictionaries, but they do some weird manual layouts. There is no property header. Rather each entry is an HBoxContainer with 2 EditorProperty. It's more complexity, and I would've attempted it until I saw that nested resources currently look like this. I feel like we should have a better idea of how to use this space first before trying to save a few pixels on the button (it might even need to be implemented differently)

I only added it because in some cases, like direct arrays of arrays of arrays, the condensed design could be less clear

Nested resources is where I like the new design because side buttons kill a lot of space usable for data. Maybe if readability is a concern you could try making the backgrounds of nested resources increasingly more opaque for deeper resources? just put a cap on the opaqueness at 3-4 levels or smth like that. quick sketch (scuffed inner contrast because I only had time to overlay colored boxes on top of the image):

Alternatively could experiment with slightly increasing border sizes to make them more discernible. Or maybe a small left margin outside of them to make them a little bit indented. Hard to say without actually trying all of those things. This can be a separate PR too, but I think there are a lot of things that can be tried to fix this without resorting to huge vertical buttons

Nested resources is where I like the new design because side buttons kill a lot of space usable for data. Maybe if readability is a concern you could try making the backgrounds of nested resources increasingly more opaque for deeper resources? just put a cap on the opaqueness at 3-4 levels or smth like that. quick sketch (scuffed inner contrast because I only had time to overlay colored boxes on top of the image):

Oh I like that design. As far as I can tell, there's no special logic for the colors/transparency of the sub inspectors, it's just drawing one of the 16 styleboxes defined in the theme under "EditorStyles". Maybe we could just adjust the bg_color for all those styleboxes, to be more colored like the inner pink one

Would it be possible to have this design for dictionaries as well?

Would it be possible to have this design for dictionaries as well?

Yeah but I'm not sure how helpful it'd be. Again this is what nested inspectors look like in dictionaries

I implemented it for Dictionaries (not pushed yet), and also embedded the key property into the label area of the value property. This way, bottom editors can take up the unused horizontal space, but idk how I feel about it aesthetically:

Before	After

This way, bottom editors can take up the unused horizontal space, but idk how I feel about it aesthetically

This is obviously a huge improvement, those sub-editors are practically unusable in the left picture. The only concern here would be whether it's easy enough to understand at a glance what is a key and what is a value, but in practice you would normally much more often use typed dictionaries rather than what you have in your example and it'll be easy to read because of the repeating data

(if readability of untyped dictionaries is a concern you could experiment with a unique style for keys, such as font color/weight/style, bg color, etc, but I don't think it will be necessary tbh)

Thanks so much for the dictionary part, I can't wait to cherrypick this and start using it for production.

Thanks so much for the dictionary part, I can't wait to cherrypick this and start using it for production.

Still have to clean it up a bit before pushing

Rebased and fixed conflicts. Also made the changes from @KoBeWi

I think putting edit button at the left of Dictionary entry will be confusing:

It looks like it would edit the key, but it edits the value.

So should I return it back to the right or just leave it for now (it's currently on the left)

As @akien-mga said: given the lack of consensus, I would keep it on the right side for now.

Ok I readded the right container and moved buttons back to the right

Thanks! Excellent job implementing such a strongly-requested feature!

@Repiteo Thank you!

I really like your design, I am very grateful to you for your effort!

@dugramen I really love this update! TileSet's various Layers sections could really use it too. This should be the default for any list displays in Godot now.

I'm in Godot 4.6 and I can't find the setting for the size?

@KoBeWi Yeah it was suggested that the layout change be a separate PR since we didn't agree on a location for the add button. So this pr currently only embeds the "move", "delete", and "pick" buttons directly into the property's header, rather than them taking up an entire column for the whole array / dictionary slot

Which separate PR?

I'm in Godot 4.6 and I can't find the setting for the size?

@TotoShampoin what do you mean size? Originally there was a setting to disable this feature for each side, but that was decided as unnecessary.

Also sorry there is no PR (from me at least) for moving the "add" button. It didn't seem like it was very desired in the first place. People were concerned with more horizontal space not vertical space. Is that something you actually wanted or you're just curious about it?

Well yeah, while I am happy for the saved horizontal space, I am currently struggling a lot with container nesting (goes dictionary → resource → array → resource → array. I swear it makes sense in my design), and it's getting to the point I am seriously considering making a custom plugin just to make the interface easier on my specific project.

But the part where the size field was going to be moved below the elements or was even gonna be removed, and the add button being moved away...
Yeah, I just found out about this MR, but I'm very much hyped by saving vertical space for those.

I did stumble across the "Debloat Array" plugin, which would've been ideal, but it doesn't work for me (no arrays in the resources being rendered at all)

@TotoShampoin makes sense. You should open a proposal or discussion with a screenshot of how it looks for you, so people can discuss what to do about it