-
-
Notifications
You must be signed in to change notification settings - Fork 21.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow pinning property values + Consistent property defaults #52233
Closed
RandomShaper
wants to merge
2
commits into
godotengine:master
from
RandomShaper:property_pin_control
Closed
Allow pinning property values + Consistent property defaults #52233
RandomShaper
wants to merge
2
commits into
godotengine:master
from
RandomShaper:property_pin_control
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RandomShaper
changed the title
Allow pinning property values in derived/inherited nodes
Allow pinning property values + Consistent property defaults
Aug 29, 2021
RandomShaper
force-pushed
the
property_pin_control
branch
13 times, most recently
from
September 4, 2021 22:46
d10cfac
to
f10090b
Compare
Is this ready for review? I am using the concept of this feature for a property editor similar to godotengine/godot-proposals#1142 |
Not yet. I hope it will be soon, though. |
RandomShaper
force-pushed
the
property_pin_control
branch
8 times, most recently
from
September 13, 2021 13:21
3ed565d
to
bc31d99
Compare
RandomShaper
force-pushed
the
property_pin_control
branch
2 times, most recently
from
September 14, 2021 12:49
3787628
to
d10a1eb
Compare
RandomShaper
force-pushed
the
property_pin_control
branch
5 times, most recently
from
September 17, 2021 12:17
0d16b67
to
4b84882
Compare
I'll change this back to draft since I'm working on an alternative approach (still compatible with the proposal). The first commit will stay the same. |
RandomShaper
force-pushed
the
property_pin_control
branch
3 times, most recently
from
September 19, 2021 17:32
a9f2fcf
to
047ee87
Compare
RandomShaper
force-pushed
the
property_pin_control
branch
from
September 20, 2021 11:50
047ee87
to
be29a3b
Compare
Superseded by #52943. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements godotengine/godot-proposals#2280.
Consistent property defaults
The first commit in this PR unifies what is considered to be the default value of a property, following the same precedence that the engine uses when instantiating an object. See the comments in the code for details. That means that Godot now has a single, universal idea of what is the default value of a property.
This (which is a follow up of #46270 + #51173) is important for the pinning (and, specifically, auto-pinning) to work reliably.
This first commit also does a lot of cleanup and refactor on the go, to remove duplicate code and make for that single source of truth goal in various aspects.
Allow pinning property values
The second commit is where the actual pinning magic happens. It implements the main idea described in the proposal, but taking some inspiration on one of the approaches suggested there, so the best of both worlds is present.
A key concept here is potential overriding. A property value is potentially overriding if the node has ancestors in the instance/inheritance chain, or if it has a script exporting that property. The latter means that this PR extends the pinnability mechanics to script export values so they also benefit from it. (Conversely, this means that the aforementioned cases where, without the protection brought by pinning, could be unexpectedly changed if some ancestor or the script exporting the variable changes are properly handled.)
Some highlights:
Only properties that are stored can be pinned. Two points derive from that:
Node
(and used in the cases of nodes that needed that). In this PR for master no cases have been found, since those properties are exposed in a different way, but the system is still there because it may be needed. In the version of this PR for 3.x a number of cases have found and been taken care of.Binary scene file format changes so properties can have the new
flags
field, which so far is onlt used for storing whether the value is pinned. Therefore, the binary scene format compatibility is broken.Text scene file format changes so the pinned flag can be stored, like this:
position = Vector2( 20, 0 ) [pinned]
. Godot versions prior to this PR will not be able to open scene text files that have pinned values.Some editor settings are introduced:
docks/property_editor/auto_pin_on_value_override
(defaults totrue
): If enabled, when you change a property value in the inspector in a potential overriding context the value is automatically pinned.docks/property_editor/auto_unpin_on_value_revert
(defaults totrue
): If enabled, reverting a value (by clicking on the circular reset arrow icon) also unpins it.docks/property_editor/show_pin_ui_only_if_override_possible
(defaults totrue
): If enabled, only properties in a potential overriding context display the pinning UI on hovering.WIth all those enabled by default, the pinning experience is something users won't almost ever have to worry about and the pinning UI only appears where relevant. That also provides the best experience possible to beginners, which won't see anything related to pinning until they start dealing with exported variables or instancing/inheritance. More advanced users are free to tweak the settings for finer control if that's what they want.
More images:
Version for 3.x submitted as #52234.