Implement inspector "Property pinning"

[reduz]

Note: This is a sister proposal to (#4273) in which both together aim to solve the problem of Viewport toolbar cluttering. To understand them properly both must be read.

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

Very often, users desire to access a property present in many objects while editing, and have them handy and ready to use.
Godot inspector can be complex in nature so finding some properties every time you need them may be a chore.
Others may also be difficult to understand or find for users who don't know they exist.

Some solutions were added recently to the editor, but they suffer from the same "conceptual disconnection" and "toolbar cluttering" as other editors there (which are intended to be solved by #4273):

Just looking at this is confusing, and it takes a lot of horizontal space in the editor and its not entirely clear what they edit. A potential solution is the contextual drawers (godotengine/godot#55630) but, as mentioned, they are not an ideal solution in many cases (as described in the other proposal).

Ultimately, they are hacks that need to be manually programmed for every feature or properties that we desired adding.

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

The idea is to, instead of adding hacks for every situation, we should simply allow for pinning of properties.

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

The pinning will not be on a "per object" basis, but instead on a "per class" basis. If you pin a property in a class, they will be pinned for all similar classes. Pinning is done as follows:

Once pinned, these properties will appear at the top of the inspector:

Some of these could come pre-pinned, and we would be able to get rid of confusing toolbars like this:

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

N/A

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

N/A

[LucaVazz]

This sounds like a very handy proposal.

Would it make sense to indicate where the property is coming from, i.e. showing the headers in the pinned section?

Also:

they will be pinned for all similar classes

I'd assume this means that all classes which also inherit from the same class where the property is originally defined will show them as pinned?

[reduz]

Would it make sense to indicate where the property is coming from, i.e. showing the headers in the pinned section?

Yeah this could work, maybe simply an icon of the type next to the name (that tells you the class on tooltip):

[MewPurPur]

This is reminiscing of Musescore's custom palettes. Musescore has hundreds of notation symbols, most of which are obscure. So they had a beginner palette (reminiscing of these drawers somewhat) and an advanced palette (reminiscing of the full inspector). But some found the beginner ones too simple, and the advanced one too complex.

So Musescore introduced a custom palette, which sends you to a menu where you pick from every type of marking and which ones you want to use. I can see something like that for Godot, a menu where you pick what properties to pin for each particular type of node.

[Calinou]

Related to #4214, which proposes pinning entire sections of the inspector rather than individual properties.

I think pinning individual properties is more useful overall (and more granular), so I'd prefer to have that instead of what #4214 proposes.

See also #2651, which is tangentially related to this proposal (but can be implemented independently of it).

[Mickeon]

The FileSystem tab has a "Favourites" section. Perhaps the act of pinning properties should be called similarly, as well?

[reduz]

@Calinou There is no reason why both cant be pinned (sections and individual props), since all you need is a base path.

[fire-forge]

I really like this idea. I think it will be easier to use and much more customizable than the toolbars.

I have a suggestion: for pinned properties, the context menu (right-click menu) should have a "Go To Property" button that would take you to the property's actual location in the inspector. It would expand any groups the property is in, scroll to it, and highlight it.

This would be useful, for example, if a Label's text color property is pinned and you want to edit its outline color, but that isn't pinned. What you could do is click on "Go To Property", and it will take you there much quicker than having to find it yourself.

---

Also, I think this could be confused with the "Pin value" feature that we already have (godotengine/godot#52943). Maybe one of these should be renamed to avoid confusion.

[h0lley]

Sounds great as a concept, but in practice, I just don't see myself using it.
I fear the effort of pinning and maintaining my pins may end up being just as great if not greater than filtering or even browsing for properties.

I may be implementing something where I constantly change property x during testing, so I'd pin it, but once I'm done with that part, that pin quickly turns into clutter, bothering me more than helping. The idea of pinning and unpinning properties all the time because I expect that I may or may not be needing them for the next thing I do does not sound efficient.

I also don't like how properties are pulled out of their context-providing groups. A property name by itself may be ambiguous without its group header. When you pinned it days ago, I imagine you may need to browse to its category to remind yourself what that property is for - which of course defeats the purpose of the pin.

How about instead, a block at the top of the inspector listing the five properties you edited last? I'll make a separate proposal.

[archerallstars]

Will this fix issue #44152?

[AttackButton]

Maybe an array with all pinned properties could be good, to iterate in a similar way like nodes do.

[me2beats]

Looks fine to me.

The pinning will not be on a "per object" basis, but instead on a "per class" basis. If you pin a property in a class, they will be pinned for all similar classes.

Does this mean the user sets this for any node and then all other nodes (with same class) have these settings?

[me2beats]

Also how would scroll work?
Are these props have a separate Scroll container?
And scrolling the inspector mean scrolling pins first, and only then scrolling regular props
Can the user completely hide pinned props when scrolling the Inspector

[YuriSizov]

I think @h0lley highlights most of the usability and practicality issues, but I have one more: how would the sub-resources/sub-inspectors be handled? Each sub-inspector would have it's own pinned section? Main inspector would accumulate pins for all currently edited classes? Either way sounds messy, to be honest, so it's interesting to see what the solution would be here.

[Zylann]

Pins could allow putting transform of Node2D and Node3D on top. It's a known property but it's always pushed all the way down, which is odd for such an important one. When it's well known or often used to be pinned, a property can probably afford been shown "out of its context". That's the only one that comes to mind as prepinned though, I can't say if I'd use the feature myself since I havent seen that in software I used before.

If sub-inspectors get pins I'd see them on top of each sub-inspector, and those can already get messy when they are deep. I don't know how good of an idea it is. I think they also already not behave like "main" inspectors, sometimes they dont show some properties or controls which they show when in "main". But I dont have other solutions than "not abusing of it". And yet in my own tools there are places I cant avoid the mess (often with lists), so yes, sometimes dedicated editors might be good to have, rather than trawling through a single monolithic nested inspector. If only inspectors were a control that can be re-used to make such tools 👀 (when applicable, of course)

I'm not a fan of pinning the last 5 edited properties. They might often change, I dont like having a shape-shifting inspector for indirect causes, pinning is more intentional.

[jordanlis]

I agree with h0lley, be careful that this feature may end up usefull but not used because people won't bother to pin for each individual node all their usefull fields.

Instead, this feature should allow to pin a field to a type of node.
Example : you pin to an individual 2D node the modulate part for example --> Then, this pinned field is pinned for every other 2D node.

In a scene with at least dozens of nodes, people won't loose time to pin to each individual node the needed field. Instead, they will use the searchbar.

[Zireael07]

@jordanlis This would also be useful, but I would mostly want this for my custom exported fields on my scenes

[jordanlis]

OK I see. But the custom fields are already regrouped in a section I think, but yeah not pinned. I see what you mean anyway.

[SirPigeonz]

Currently, I have a huge problem when I have to edit PROPERTIES that are far apart. Like for example when tweaking and experimenting with particles - I have to edit for example both material props and particle process material props at the same time back and forth, back and forth. I waste most of my time on scrolling. This feature would help a bit...