Disabling Script Editor also disable the ability to create "New Scripts" from inspector

[AndreSacilotto]

Godot version

3.5.1 and 4.0.RC2

System information

Windows

Issue description

When disabling the script editor feature you also lose the ability to create new scripts from nodes.

Why I disabled it?

I use c# on external editor, and I'm annoyed by having a tab that I never use. So I decided to disable it, but for my surprise it disable the ability to create new scripts from inspector, and also the double-click functionality from FileSystem.

Why it's a bug?

Script Editor:
Allows to edit scripts using the integrated script editor.

The description of the script editor feature don't say that "you will be disabled of creating new scripts from inspector".
I stayed 1 week thinking it has just a bug with the new godot version, but nope it also happens on 3.5.

Steps to reproduce

1. Editor -> Manage Editor Features
2. Disable Script Editor
3. Select any node right click on script -> New Script
4. Nothing will happen

Minimal reproduction project

Editor bug

[nongvantinh]

The reason is when you want to disable the any future, it also disallows you from interacting with it.

Disabling some future means you will not use them anymore, and because that future causes distraction that would lead to less productivity.

For instance, an artist might want to work with the scene only, a teacher thinks that hide some future can help students focus more on the topic, ...

[nongvantinh]

If you really want to disable Scripting Editor's future but still want to use some functionalities of it.

Seeing you currently using a RC version, and I have made a PR for this, you could pull that branch to your PC and compile it yourself.

And from now on, whenever you need some future that is specific to your need. You can modify the source code and implement it yourself. That's how companies do.

[AndreSacilotto]

I'm just documenting a probably unintended behavior, in other words reporting a bug.

You don't need to replicate what akien-mga said in your PR. And you probably miss understood what he said there, he was saying that the alterations you have done breaks the actual intended behavior.

So to solve it you would actually need to preserve the old behavior while adding a new one.

A idea would be split script editor feature into two other options/features "Script Editing" and "Script Text Editor", so preserving the old behavior while adding a new one.

Idk if it bothers me enough to try to implement it or not, I will see.

[nongvantinh]

You're taking it personally.

Disabling some future means you will not use them anymore

If the design was to disallow the usage of that future, then why would we add something that will break the design and the abundant code added only benefit a few people?

Because you were reported a bug, and I feel I can fix it so I create a PR for this issue without knowing the original design was to disable that future completely.

I consider your case, you

some times I missclick

and cause the editor to switch to the scripting tab was not a big deal.

And the modification only benefit for you, so I explained more about the design for you and I also guide you to use my PR for your needs and if you need more, you can modify it yourself.

Reference:

1. The problem has to be complex or frequent
2. your changes have to be generic enough to be beneficial to all users

[AndreSacilotto]

@akien-mga
Could you point out where that use case is explicitly said in the docs I can't find it.

@nongvantinh
What you mean by future are you misspelling feature? Or is some kind of term?

A issue not always need to resolved with a PR to the engine some times is just missing documentation.

Sorry if you think I'm being aggressive, without the nuance of speak I always seems aggressive (even this phrase sounds like mockery ): )

and cause the editor to switch to the scripting tab was not a big deal.

Shame on me, I have written a unrelated issue as exemple my bad, I will fix that.

[nongvantinh]

It's 1 AM on my side, and I've been working all day long to care more about grammar mistake.

It was my fault for typing "future". when it means feature. Just as i means j

We don't discuss grammar mistake here as we are not native speakers and I also notice yours. Let's get back to the base case:

1. You report a bug, it labeled bug and it means describes something that is not working properly.
2. A bug needs to be fixed, and I help the developer fix it by creating a PR of my own free will so they can spend their time on more important task.
3. Until akien-mga point out this is intended behaviour, so I guide you to use it for your needs.

Furthermore, the documents are provided for reference as to why the PR will not be merged, not as proof.
Or to tell you why that "feature" behaves like that.

[akien-mga]

Please keep the discussion focused on the issue. There's a bad vibe in the last interactions which seems completely unnecessary.

Now, this is no way a priority and we're not going to merge any PR for this issue during release candidate stage for 4.0, so there's no need to rush things.

I pointed out a potential difference in expectations for what this should do. It can be discussed peacefully, and there's no rush.

[Zireael07]

@akien-mga I think I saw a comment by you explaining two different expectations, but I don't see it here? Were there two threads or something?

Personally, if the design is to disable creating scripts entirely, the option should clearly say so both in the settings and in docs. Tbh, I am thinking that the setting should be renamed to "disable scripts" and the current "disable script editor" would then work for the "I want to use external editor only" use case. (And both settings should be a thing!)

[akien-mga]

Yes, I commented on the PR: #73760 (comment)

I'll repeat it here:

The main question is what is the use case for disabling the script editor. There seems to be conflicted use cases:

• Disabling all scripting functionality (e.g. for teachers who want to teach students with only nodes/inspector/animations/premade custom nodes but no scripting initially). That's what the current implementation was intended for.
• Hiding the script editor because users want to use an external editor, and thus remove the internal editor from the interface. This is what this PR seems to allow, but breaks the above requirement.