Make possible to favorite properties in the inspector

[YeldhamDev]

Closes godotengine/godot-proposals#4274.

2024-09-24.10-57-26.mp4

Limitations

Incompatible with built-in scripts, as validating the favorites file with them in mind would mean extra loading of scenes at startup.

Sponsored By: 🐺 Lone Wolf Technology / 🍀 W4 Games.

[timothyqiu]

Favoriting Button's tooltip_text and text makes two "Text" properties 🤣

The group "Tooltip" is lost here.

If this is not expected, I think displaying "Tooltip Text" is not an ideal solution as it means doubling translator's work for grouped properties. Maybe displaying a group that's always unfolded?

[Mickeon]

This is not necessarily related to this proposal as the rest of the Inspector suffers from it too, but I don't like that there's no way to know that Inspector categories can be right-clicked (not even a text color on hover). This makes the "Unfavourite all" option undiscoverable.

[tetrapod00]

Could we make Node3D.Position, Node3D.Rotation, and Node3D.Scale (and the corresponding 2D properties) favorites by default? This would make the default editor show those properties at the top of the inspector, which is a very common request. It would also increase the discoverability of this feature.

Favoriting/reordering the entire Node2D/Node3D property block to the top of the inspector would also be a way to do this, but this PR seems to only allow favoriting individual properties.

[ryevdokimov]

Could we make Node3D.Position, Node3D.Rotation, and Node3D.Scale (and the corresponding 2D properties) favorites by default? This would make the default editor show those properties at the top of the inspector, which is a very common request. It would also increase the discoverability of this feature.

I think the inspector can get crowded pretty easily and would prefer not to have additional and redundant data shown by default.

[tetrapod00]

I think the inspector can get crowded pretty easily and would prefer not to have additional and redundant data shown by default.

Notably this implementation pulls properties to the top, it doesn't duplicate them. Setting these properties as favorites by default does obscure the fact that they are Node3D properties, though.

[ryevdokimov]

Notably this implementation pulls properties to the top, it doesn't duplicate them. Setting these properties as favorites by default does obscure the fact that they are Node3D properties, though.

I should have paid attention more, thanks for pointing that out. That is surprising though, and not what I would expect for the reason you stated. I am ambivalent about the fact it does that, but I think it makes a different argument against having them be favorited by default.

[jaydensipe]

Setting these properties as favorites by default does obscure the fact that they are Node3D properties, though.

Wondering if something could be done like this, where it would show the Object/Class name before the property?

[tetrapod00]

My view is that for most workflows involving the editor, you want to access position, rotation, and scale most often, at the top of the inspector, then you want to access properties you defined on your classes, then you want to access properties on built-in parent classes. As is, the ordering of properties is mostly good except for the fact that transform properties are hidden at the bottom of the list.

If most people setting up their editor will favorite these, then we should do it by default. The favorites are stored in editor settings and are per-project, so whichever default is chosen does matter - each new project will be affected by it. It will be three clicks to change it, whichever default we choose, so let's choose the default that serves the most people. Of course, if the preference is evenly split, we can decide in favor of no default favorites.

[ryevdokimov]

If most people setting up their editor will favorite these, then we should do it by default.

Agreed.

If/when this gets approved and merged, I would suggest a separate proposal and PR be made.

[tetrapod00]

Also, to bikeshed the name, I do slightly prefer the old "Pinned Properties" name from the original proposal.

[Mickeon]

If we settle on "pinning" properties, the "Pin property" feature has to be renamed to something else. To be very fair, its name has been potentially misleading as is, already.

[tetrapod00]

If we settle on "pinning" properties, the "Pin property" feature has to be renamed to something else. To be very fair, its name has been potentially misleading as is, already.

Oh, I thought that there was already something called "property pinning" but googling that led me to the original proposal for this new feature. "Pinning properties" definitely describes this feature more than the existing one. But changing the name of an existing feature is probably too much, just to have a slightly better name for the new feature.

[KoBeWi]

It can be called Sticky Properties or something similar.

[YeldhamDev]

Alright, now properties are shown with their respective sections (always unfolded), to both give context, and prevent ones with the same name mixing up.

[pineapplemachine]

I foresee not finding properties in the expected place, because they are moved rather than duplicated, being a potential source of confusion and irritation for larger projects where you might not remember what properties were favorited and might have scrolled past the favorites category without noticing the property there.

At minimum I'd really like to see an editor toggle for whether favorited properties are moved or duplicated.

[KoBeWi]

• Favorite and Pin should be in the same separator group.
  
• I noticed Favorites sub-sections can't be folded. If it's not much problem, they should be foldable, unfolded by default.
• Some weird bug:

godot.windows.editor.dev.x86_64_zSxpkGX2Dl.mp4

[KoBeWi]

Patch that removes override menu:
menu_no_override.txt
The regular menu is created on demand. Makes the code simpler.

[YeldhamDev]

Separator removed and iterators fixed.

[YeldhamDev]

@KoBeWi I added your patch to the code.

[KoBeWi]

Looks good now.

After #97352 we can refer script favorites by UID instead of path, which would make the FileSystem Dock changes unnecessary.

[Calinou]

Tested locally, it works as expected.

Note that this doesn't affect the remote inspector, which doesn't support favorite properties.

This makes me wonder if we should bring further attention to the Favorites section, e.g. by using a colored icon, or by adding a tinted background:

[akien-mga]

Looks good to me. I've been expecting this kind of feature for a long time!

[Repiteo]

Thanks!

[nuclear]

Could there be an option to have the favorited items show up at the top and where they used to be? I already see myself looking for some aspects because I forgot they're at the top.