Make several actions in the Inspector dock more obvious

[YuriSizov]

Closes godotengine/godot-proposals#2047, and also adjusts the looks of the top part of the Inspector dock to make other actions available more obvious.

Original version

Here it is in action:

2021-06-04_02-04-23.mp4

Original version

1. Clickability of the current object's name was made obvious, with a non-flat button design and an arrow at the right end.
2. Extra tools menu was reorganized to only include things that make sense for properties, as the button was called "Object properties" and we have a better place for object-specific actions at the top. The button itself was moved next to the properties filter.
3. Therefore object-specific actions were added to the topmost bar; and "Save"/"Save as" was removed from the context menu because it already exists in the topmost bar.
4. Several names, tooltips and texts were adjusted to better reflect their actions.
5. The list of sub-resources had its name capitalization logic improved.
6. The PopupMenu for sub-resources was made a bit shorter than full width to give user an ability to see and click the dock underneath. Especially important for huge sub-resource holders, like themes. This change was reverted (but still present in the clip; so imagine the popup at the button's width when you watch it).

---

Should be possible to cherrypick this to the stable branch.

[YeldhamDev]

Ideally, the popup's width should be the same width as the button itself. Like how it works everywhere in the editor.

[YuriSizov]

@YeldhamDev Is the reason I've provided not a good one?

[YeldhamDev]

@pycbouh The fact that the sub-resource popup can get huge enough to be bothersome is kinda of a problem of its own that should be addressed directly, rather than hacks that break consistency.

[YuriSizov]

I think that's two different UX problems from the same situation. The fact that it's a huge list sometimes and is barely usable is one, and the fact that it's big enough to cover the dock with it so you can't click on a safe area within is another. It's also not that different from the resource picker, which has a popup as wide as its smallest item, not as the whole control:

But oh well, this is not a feature I want to argue about 🙂 Reverted.

[YeldhamDev]

It's also not that different from the resource picker, which has a popup as wide as its smallest item, not as the whole control

That's because the whole control is actually that small highlighted section. 😉

[YuriSizov]

That's because the whole control is actually that small highlighted section. 😉

Not exactly: for an empty picker clicking on the main part also brings that menu up. That's a combined control with complex behavior, so I'd consider the whole thing as a unified thing.

[YeldhamDev]

Not exactly: for an empty picker clicking on the main part also brings that menu up. That's a combined control with complex behavior, so I'd consider the whole thing as a unified thing.

Technically, yes. But all it does is telling the button on its right to trigger its popup. But whatever, we're getting offtopic now. 😝

[EricEzaM]

For the sub resources drop down, can an item be added to the top of the popup that is a read-only separator (so it has the line) which says 'Sub-Resources'? When the list is empty, it says 'no Subresources found', which is the first indication of what this list actually displays. I think it should be more obvious exactly what the list is showing.

[YuriSizov]

@EricEzaM I guess it is technically possible, yes. Do we do this anywhere else in the editor? Keep in mind that there is a tooltip on this button, stating "Open a list of sub-resources.", however useful it proves to be.

[EricEzaM]

Ah yeah I didn't realise there was a tool tip, I didn't test it cause I'm not on a computer atm but I think a tool tip would be fine

[akien-mga]

I haven't tested yet, but I'm concerned that the many new buttons in the top bar force a significantly higher width for the inspector, which could be problematic on small screens.

[YuriSizov]

@akien-mga This is certainly true, though I'm not sure that narrow columns are comfortable to work with, even when possible to have. Here's a comparison:

Before | After

It's about twice as wide now, which I find a comfortable width to be able to read all the options and have large enough areas to interact with. I guess an easy change can be moving the "Docs" button next to the current object's name, above the tools button. That would give us another 30 pixels or so.

After with Docs moved

[KoBeWi]

The version with moved Docs is better. But you could leave the separator.

[YuriSizov]

@KoBeWi You mean the separator in the top bar that used to delimit the docs button from the other 3 new buttons? It will look weird when they are spaced out.

---

By the way, here's the look for the remote scene:

[KoBeWi]

You mean the separator in the top bar that used to delimit the docs button from the other 3 new buttons?

Yes. The 3 buttons to the right are related, so it makes sense to group them.

[YuriSizov]

Okay, I went with the right alignment for the separator (as opposed to the other option).

Separator makes it a bit wider, of course: Current state

[YeldhamDev]

@pycbouh I personally think it could do without the separator. Dangling separators are avoided across the editor, and avoids adding to the minimal size with was the point here in the first place.

[YuriSizov]

@YeldhamDev I can see both points: it looks better with the separator when at min size but it looks better without it when wider. I'm fine with whichever option, so if we could agree on one I'd implement it 🙃 We need a tiebreaker?

[Calinou]

I can see both points: it looks better with the separator when at min size but it looks better without it when wider. I'm fine with whichever option, so if we could agree on one I'd implement it upside_down_face We need a tiebreaker?

I think we should keep the separator. If the dangling separator is a problem, you could hide it dynamically if the inspector gets wide enough too. (That said, we may want to always draw the separator in case an editor plugin wants to add its own button there.)

[YuriSizov]

So if we are keeping the separator, this is good as is? Or are there other strong opinions?

[YuriSizov]

Okay, we've discussed on RC that the three new buttons from the top bar can be hidden behind a popup menu. This should serve 3 purposes: not overburder the user with a lot of buttons; help with the min width; and also likely remove the need for the separator that was a point of conflict above 🙂

Update is coming soon.

[YuriSizov]

Okay, done. More compact, no separators, no overwhelming actions on the top bar.

2021-06-04_02-04-23.mp4

Should be good to go!

[akien-mga]

Haven't reviewed code in depth or tested, but latest screenshots look great and this was positively discussed to reach consensus on RC, so seems good to go.

[akien-mga]

Thanks!