An option to automatically close dominant script on scene close

[kubecz3k]

There is an option to automatically open scene dominant script when user is opening new scene. I think it would be logical to allow editor close dominant script when user is closing the scene. Optionally editor can check if given script was opened automatically and close it only if this is true. Update: This issue is on how to make "open dominant script on scene change" option better.

[kubecz3k]

We had a discussion with @akien-mga on the irc on couple problems with this feature and how to surpass them.

• Generally we both agree that script should not be closed if there is opened another scene for which given script is dominant also.
• If I remember correctly @akien-mga would want to take this further and don't allow script to close also when it's linked to at least one first-level child of any other opened scene.

I personally don't like second option to much because quite often I have opened scene with level on which there is quite a lot of different subscenes on first level, so autoclose would not work for me quite often in this case. But in this case it would be possible to add some check to take into account if given script was edited in this 'opening', or alternatively check if its script was opened automatically or manually (and autoclose only if not edited / not opened manually / or the best: combine these informations).

[akien-mga]

To clarify what I was proposing, I'll describe a possible implementation directly:

• 1a. Case 1: script is open manually, don't do anything specific
• 1b. Case 2: script was opened automatically when opening a scene: it's either the script of the root node or of a child node (I guess scripts of subscenes are not opened automatically). Add all those scripts to an array that keeps track of automatically opened scripts (let's say the array is auto_opened).
• 2. When closing a scene, check for each script that has been opened automatically if it's in the array auto_opened, then iterate on all opened scenes to check if the script is used by one of those scenes. If no other scene is using it, the script can be safely closed and removed from auto_opened.

Note that for (2), checking the other opened scenes might even not be necessary if all automatically opened scripts are added to the array (even duplicates). The closing a scene would just remove one reference to each of its scripts in auto_opened, and only close them if they were the last occurrence in the array (if not, it means that another scene flagged them as auto_opened).

Hope this makes sense :)

[kubecz3k]

@akien-mga looks good to me, under that condition from your note(2), that duplicates are added to this array.

[razcore-rad]

I don't like this idea. I would rather have the text editor independent of the scene. That makes more sense to me. Why have scripts attracted to scenes (editor-wize) anyway? The text editor should behave in essence just like an external text editor, with the added facility of automatically opening scripts that were not explicitly classed.

[nunodonato]

Hi agree with @razvanc87 , I find no sense at all in this tight relationship. Godot supports external editors, the internal editor should behave the same way, and try to be a good editor. This behaviour makes it really confusing to use and counter-intuitive.

[kubecz3k]

Well it depends, if you are working on relatively big project you are unable to remember all the script names (or from what exactly subscenes given scene is build), and you usually open some 'main entity scene' and then go deeper and deeper with 'open in editor' option, until you find scene/script that interest you. If you do this once you will have have opened ~=5 redundant scripts this way. And when you are working on a bigger project you are moving between scenes this way all the time and script panel becomes a mess very fast. Since there surprisingly a lot of controversy about this option I think that if it will be implemented it should be independent from "Open dominant script on scene change".

[razcore-rad]

I don't think I understand @kubecz3k. This is how I picture working (and am currently working with the editor).

1. attach script to node -> opens in editor
2. do some work, move to other script etc.
3. usually when I want to change a behavior or some node I don't go looking for the script itself (unless I remember explicitly the name), I instead go to the scene/node and open the script from there
4. text editor reacts to button press and focuses on the script

But this can be all very well independent of scene - text editor integration. When you press the "attach script to node" button, if the node already has a script attached, then just open up that script in the text editor, and forget about it. I mean the node knows where the script is stored on the disk. So it would be just like saying "hay... I see I have this script resource attached to me, let me open this up for you in vim". Every time you click on that button it just tries to open up the same script. The text editor should know if the script is already loaded and it won't try to duplicate it, just focus on it, like any other text editor. I think this is the most natural way of having the text editor.

To tell you the truth, if vim would have code completion I would ditch the built in text editor in a heart beat.

[kubecz3k]

@razvanc87 Are you using "open dominant script on scene change" option? Because if not then we are using editor in different ways (and my proposal don't make any sense for if you are not using this option, and this issue is on how to make this option better).

[razcore-rad]

@kubecz3k, oh right, I never heard about that option before I thought that's some terminology you guys use :)... but even so I would probably still do it the way I'm doing it now :d

edit: yah, I checked, this "open dominant script on scene change" is on for me, doesn't this just open up the script/scripts if you change scenes? that makes sense, but if I want to find a certain script attached to some node, then I just go to the scene tree and click on the script button which focuses on the right script in the text editor... that's what I meant, regardless of this option

[kubecz3k]

@razvanc87 The problem is, when you have complicated scene that have deep structure of subscenes (scene made of subscene made of second-level subscene made of third level subscene and so on) and you are moving inside this this structure by opening deeper subscenes, you got a lot of scripts opened in the process (the scripts that don't interest you at all), and your scripts panel gets bloated very fast. To be more preciselly, you told that you 'just go to the scene' and open proper script.. well this is not possible if you dont know what exactly subscene you are looking for (and this happens when you have 450 scene files in your project). Besides in my workflow there is no strong separation between scripts and scenes (because since when it's possible to inherit scenes, for me it's a lot better to create companion scene that holds script everytime when I see the need for creating new script (since I usually can't tell if this script will not evolve in something bigger in a couple months, and this way I'm protecting myself from painful refactoring in the future - besides script almost always need to be attached to some concrete node types, so why not to thread it as your own node type, especially that in a couple of months I don't need to remind myself to what type of node I need to attach this script, as well as what companion nodes are needed for it to work - Instead I just attach a scene and it's there working, just like one of those predefined build in nodes) <- it's a very nice workflow for long term project.

[kubecz3k]

Another issue related to "Open dominant script on scene change" option: https://github.com/godotengine/godot/issues/5646

[akien-mga]

Not critical for the upcoming 2.1, so moving to the next milestone.

[Anutrix]

Maybe we can get a milestone and/or remove the junior job label as it doesn't seem like it.

[akien-mga]

I think after 4 years we can see that there hasn't been a lot of interest in this feature.

If it's still wanted, I'd suggest opening a proposal on https://github.com/godotengine/godot-proposals which will give it more visibility and is the new workflow for feature proposals.