-
-
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
Fix node names of submenu items across the editor #84617
Fix node names of submenu items across the editor #84617
Conversation
Also removes some programmer remarks and fixes some docs.
@@ -796,15 +796,14 @@ AnimationNodeBlendSpace1DEditor::AnimationNodeBlendSpace1DEditor() { | |||
|
|||
error_label = memnew(Label); | |||
error_panel->add_child(error_label); | |||
error_label->set_text("hmmm"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol
_menuPopup = new PopupMenu | ||
{ | ||
Name = "CSharpTools", | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what's the preferred style but I notice the AddChild
function above does this inline:
_menuPopup = new PopupMenu | |
{ | |
Name = "CSharpTools", | |
}; | |
_menuPopup = new PopupMenu { Name = "CSharpTools" }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's supposed to be inlined when it's just one property? cc @raulsntos
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think we tend to inline them when it's just one property and the line is not overly long. But we don't really enforce this so we're probably not consistent everywhere. I think it's fine either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
I was initially confused by the bug report / reason for enforcing a valid non-autogenerated name for PopupMenu
, as usually all nodes in the end can do their work without hassle regardless of their name.
But looking at the API, I now understand that there's a two step process where PopupMenu
must first be created, named, and added as child, for that name to then be passed as argument to add_submenu_item
. Seems a bit weird to rely on names like this, but that's a pre-existing problem we won't solve here :)
Yeah, something that we should've fixed in 4.0, but alas... |
Looks good. Thank you!
As for the open question. I think both changes are appropriate: allowing The reason I feel validation should allow unnamed nodes is because there are still many nodes in the editor that are unnamed (such as the top & run bar nodes). The consistency and validation seems wavy in those areas. But I am new to the source code so take my input with a grain of salt. |
Thanks! |
Fixes #84582, a regression from #84183. Also removes some programmer remarks and fixes some docs.
There is still an open question whether this validation is excessive or not, whether we should allow generated names here or not. We might want that, which means we need a second version of
validate_node_name
which allows@
specifically. But I would argue that we want the user to name their node here. And the case of the C# module was the only place where we forgot to do that.