Skip to content
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

Editor: Remove unused Class Name field from Create Script dialog #78573

Merged

Conversation

dalexeev
Copy link
Member

@dalexeev dalexeev commented Jun 22, 2023

@adamscott
Copy link
Member

What happens when a user don't supply a class name?

@AThousandShips
Copy link
Member

The template line is removed, at least that's how it seems in the source

@adamscott adamscott modified the milestones: 4.x, 4.2 Jun 22, 2023
Copy link
Member

@adamscott adamscott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this would need thorough testing (as this is something that is used frequently), I suggest to merge this PR right after the 4.1 release. We will be able to get some feedback from the users if this PR is alright.

So, you get my pass. Thanks @dalexeev!

@dalexeev
Copy link
Member Author

dalexeev commented Jun 22, 2023

What happens when a user don't supply a class name?

Good point. The field is not filled automatically. If the user leaves it empty, then a script without class_name will be generated. I think we should add an "Optional" placeholder to make this more obvious.

I suggest to merge this PR right after the 4.1 release

I'm not rushing anyone with this, sorry if I'm distracting. I just did not find today how I can help with 4.1.

@adamscott
Copy link
Member

I'm not rushing anyone with this, sorry if I'm distracting. I just did not find today how I can help with 4.1.

Don't worry. @akien-mga said that he was happy to have PRs ready to merge right after the release of 4.1.

@adamscott
Copy link
Member

I think we should add an "Optional" placeholder to make this more obvious.

Maybe we could otherwise add a green statement that say that the class will have a specified class name if one is submitted. If there's no class, then just don't have that statement. Usually, placeholders are used to define what is needed in the field, not that a field is optional.

@akien-mga
Copy link
Member

akien-mga commented Jun 22, 2023

Yeah it's good to think about the UX a bit and the implications here. If the UI encourages users to name all their classes, they might end up with hundreds of global named classes where it's not needed (and thus potential conflicts, or slowdowns in parts of the editor that rely on querying global classes).

@adamscott
Copy link
Member

If the UI encourages users to name all their classes, they might end up with hundreds of class names where it's not needed.

The UI could say something like - A global class named "MyClass" will be created

void ScriptCreateDialog::_class_name_changed(const String &p_name) {
is_class_name_valid = _validate_class(class_name->get_text());
is_class_name_valid = class_name->get_text().is_empty() || class_name->get_text().is_valid_identifier();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should check if the class has a name already used by a native or a global class. Then, we could output a custom error message about that.

@aaronfranke
Copy link
Member

Is this really the right move though? I think it would be better to remove this field. It's easy for the user to write class_name manually. Having this in the UI adds clutter and encourages users to name all of their classes, which is often not desired since it will fill the Create New Node dialog with tons of useless entries.

@dalexeev
Copy link
Member Author

There is an issue and a proposal about it, and there is also a similar proposal about the node name field in the node creation dialog, so I thought that users want this feature. But given the possible misuse of this field, I agree with you that it's better to remove it.

@dalexeev dalexeev force-pushed the editor-create-script-class-name branch from d7959a8 to ea1a0e0 Compare June 23, 2023 07:15
@dalexeev dalexeev requested a review from a team as a code owner June 23, 2023 07:15
@dalexeev dalexeev changed the title Editor: Allow to specify class name when creating script Editor: Remove unused Class Name field from Create Script dialog Jun 23, 2023
@dalexeev
Copy link
Member Author

I have updated the PR. But it is possible that in the process we can return to the old version or come to something else.

@akien-mga
Copy link
Member

akien-mga commented Jun 23, 2023

Be careful removing the feature, AFAIK it's required for C# scripts (and that's the reason this was added in the script create dialog). Any C# class needs to have a unique name (but it's not the same as the global script classes mechanism).

@dalexeev
Copy link
Member Author

I haven't tested this, but for C# nothing should change, the class name is generated from the file name as before.

Copy link
Member

@aaronfranke aaronfranke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support this change, but I won't give it an approval because there are some other possibly unrelated changes in this PR like changes to the script templates, and I don't know if those are desired to have in the same PR or if they should be split off (or maybe, the removal of the unused field should be the one split off).

For C#, it is generally expected that the class name should match the file name, so I don't think we need a separate field for specifying the class name.

@dalexeev dalexeev force-pushed the editor-create-script-class-name branch from ea1a0e0 to 26ce861 Compare September 12, 2023 09:51
@akien-mga akien-mga merged commit 1a0e653 into godotengine:master Sep 25, 2023
16 checks passed
@akien-mga
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants