Unify tab list for scene editors, script editors, any other editor types

[gamedev-pnc]

Describe the project you are working on

This is proposal about core experience of navigating in Godot Editor. For any game developed in Godot Editor.
I'm experienced programmer (~25 years), but I'm new Godot user and want to contribute. This is a UX proposal, but I'm not familiar with implementation details yet, it can be discussed separately.

Describe the problem or limitation you are having in your project

There are multiple interconnected UX problems. Each of them can be solved separately, but it would be partial fixes, so I propose a unified solution for them. So problems are:

1. While in the Script Editor, you click on the scene tab - and nothing happens. This is clearly a UX bug.
2. While in the Script Editor, two places in the interface indicate wrong context (see image). As if I'm working in the context of the scene "Game", but I'm working with script "Tools" now:
   
3. While in the Scene Editor, you don't see list of the opened scripts, so navigation becomes inconvenient (can use shortcut "Quick Open Script", but we're discussing UI here).
4. Some editors are accessed in the top (2d, 3d, scripts), there are shortcuts for them. Other reside in the bottom (Animation, Shader Editor), no shortcuts for them.
5. No classic Ctrl+Tab shortcut to switch between two last opened tabs. This feature is presented in almost every other editor (IntelliJ IDEA, JetBrains Rider, Visual Studio Code, Notepad++, etc.)
   5.1. While in Script Editor, you have to navigate through scripts via Alt-[-] and Alt-[+], but it's not the same (sometimes it requires multiple presses to skip all visited places in the single script file). Or you navigate via Ctrl+Shift+[,] and Ctrl+Shift+[.], but it's not the same, too (order of the scripts in the list, not the order you visited them).
   5.2. While in Scene Editor, Ctrl+Tab works for scenes, but it scrolls through the entire sequence of opened scene tabs.
   5.3. And, of course, you cannot switch between scene and script back and forth. But it's a common working process for many developers: switch back and forth between two semantically connected contexts (be it a script, scene or anything else), when you edit them together. The absence of this simple feature is hell of an inconvenience.
6. While in the Script Editor, select and open a scene in FileSystem. Scene editor doesn't appear.
7. While in the Script Editor, select and open a scene via shortcut Quick Scene Open... Scene editor doesn't appear. So it's not "Quick" in any sense, because you have to manually extra switch to the corresponding 2d or 3d editor.

Yes, there are many similar proposals already. I added a new one to:

1. offer a unified view of several interrelated problems and to formulate some points more accurately.
2. emphasize again how important this topic is.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

1. A single unified list of polymorphic tabs (for scripts, editors, any editable/viewable resource). Each tab has own processor (Scene editor, Script editor, Image viewer, PlainText editor, Animation editor, State Machine editor, etc.)
2. User can switch between any two of them using Ctrl+Tab (this simple feature would add great flexibility in conjunction with unified tab system).
3. Editor settings allow to place tabs horizontally (as scene tabs now) or vertically (as script list now) to satisfy different user preferences.
4. Adding a new custom editor type (tab type) fits within a unified approach.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I'm new Godot user and want to contribute. This is a UX proposal, but I'm not familiar with implementation details yet, it can be discussed separately.

If this enhancement will not be used often, can it be worked around with a few lines of script?

This enhancement will be used always, it's about core experience of navigating in Godot Editor.

There are multiple UX problems. Each of them can be solved separately, but it would be partial fixes. This proposed solution solves described issues in a unified manner - and also improves flexibility and conceptual simplicity for adding more working contexts, developing more custom editors/viewers for other asset types.

Is there a reason why this should be core and not an add-on in the asset library?

Godot Editor is great in many ways, but (regarding described issues) it has UX bugs and favors counter-intuitive workflow in its core. It would be inconvenient if every developer would have to search for a custom add-on and add it to every project to solve these issues. I believe that proposed approach would dramatically improve experience and reduce frustration of Godot users, especially for new ones.

[Calinou]

• Related to Improve unintuitive tab - content view behaviour #966,
  Replace left side column in script editor by moving the functionality #5314,
  Merge scene tabs with script tabs in the tab bar at the top of the editor #4457 and
  Make script list only display scripts relevant to the currently edited scene #7838.

5.2. While in Scene Editor, Ctrl+Tab works for scenes, but it scrolls through the entire sequence of opened scene tabs.

This behavior is similar to what web browsers do by default. History-based tabbing is provided in Firefox as an option, but it's not the default. I would prefer Godot to follow what web browsers do out of the box (especially Chromium-based browsers).

[gamedev-pnc]

@Calinou, browser-oriented approach that you prefer is convenient for many people, but it's implemented already. Switching between two last tabs is default behavior for Ctrl+Tab in all programming IDE that I know, many people got used to it (also it would give great flexibility in conjunction with unified tab system), and it's not implemented in Godot Editor. No matter what default behavior should be, I believe we need both options available.

[gamedev-pnc]

Guys, who downvoted proposal. Could you please share your feedback or reasons for the negative rating? It would be helpful for us to understand your perspective.

[gamedev-pnc]

@jmarceno, thank you for feedback! I understand your workflow, and my proposal doesn't break it.

I think that any proposal that removes the ability to have the scene tree and full script editor side by side would make things worse

My proposal doesn't remove the scene tree. Just like now, scene tree can show a structure of the last opened scene. So it can be shown always, no matter what script tab is active (just like now).

Item 1 is not a UX bug

I's a bug, because it breaks classic "Principle of least astonishment" ("principle of least surprise") that is fundamental in user interface design:
https://en.wikipedia.org/wiki/Principle_of_least_astonishment

if I want to change to 3D, I click the proper button

Why scene tab button shouldn't always open that scene's 2D/3D editor? It's clearly semantics of that button.
If user clicks a tab button, it means that he/she wants to open that tab.

If I'm writing a script with the built-in editor (my main workflow), I don't want to be sent back to the 3d view when I click the scene tab.

Then you just don't click the scene tab button.

I see that my proposal still supports for your workflow, but adds support for other workflows, too. And it aligns with "Principle of least astonishment".

[gamedev-pnc]

Added to the proposal:
7. While in the Script Editor, select and open a scene via shortcut Quick Scene Open... Scene editor doesn't appear. So it's not "Quick" in any sense, because you have to manually extra switch to the corresponding 2d or 3d editor.

[yosoyfreeman]

I personally don't believe any of this are problems or bugs, bug intended behavior. While doing a lot of tricks under the hood to save you a couple of clicks can be good some times, Godot workflow makes a clear distinction between 3D editor and scripting tools. Each panel have its own function and as such you don't always want them in sync.

[gamedev-pnc]

Godot workflow makes a clear distinction between 3D editor and scripting tools

2 and 4 issues in my list show that "distinction between 3D editor and scripting tools" is not clear.
I would not call it "Godot workflow", because there could be multiple "Godot workflows", respecting different user preferences.

[yosoyfreeman]

in 2 you have a selected scene, which shows properly on the scene tab. Then, you have a script opened, which do not relates to the scene.

4 is frequent misconception. 2D, 3D and scripts are different environments, while shaders, animations etc depend on the selected nodes, and as such are auxiliary tabs, not environments.

[AThousandShips]

For any complex workflow or environment it's impossible to create a UI or workflow that is universally intuitive, because people work and think differently

I find the workflow of Godot to be intuitive, and it's by no means an unintuitive workflow, some software have workflows that confuse most people, Godot is not one of those

I don't think that the UI should be changed, or add different settings for it, because it has a learning curve for some users

When something doesn't work as you assume or expect, the best way is to learn and adapt, just because it doesn't click with you immediately doesn't mean it's bad or unintuitive

[gamedev-pnc]

in 2 you have a selected scene, which shows properly on the scene tab. Then, you have a script opened, which do not relates to the scene.

Please read my answer to @jmarceno, where I clarify that.

Also, as @jmarceno mentioned, he doesn't want absolute "distinction between 3D editor and scripting tools", since he needs scene tree always to be shown.

4 is frequent misconception. 2D, 3D and scripts are different environments, while shaders, animations etc depend on the selected nodes, and as such are auxiliary tabs, not environments.

What if you need visual State Machine editor? For example, plugin editor for any custom asset? It doesn't depend on the node, but on resource.

[yosoyfreeman]

With all my respect, i read the whole conversation, that's why I'm trying to explain the behavior. Things are not bugs just because you don't like it. The folks working on this have reasons to do stuff the way they do and this is not the first conversation born of misunderstanding the editor in first place.

[gamedev-pnc]

it's impossible to create a UI or workflow that is universally intuitive

Not "universally intuitive", but maximum possible intuitive.
https://en.wikipedia.org/wiki/Principle_of_least_astonishment

[gamedev-pnc]

Things are not bugs just because you don't like it. The folks working on this have reasons to do stuff the way they do and this is not the first conversation born of misunderstanding the editor in first place.

Please explain, how a not working button is not a UX bug?

[AThousandShips]

Most users find it intuitive, that's why you don't see these kinds of proposals constantly, but a few users struggling with it, the changes you suggest would IMO be less intuitive and less convenient

[gamedev-pnc]

the changes you suggest would IMO be less intuitive and less convenient

Actually, the changes I suggest (unified tab list) is a common approach in almost every IDE and editor out there.

that's why you don't see these kinds of proposals constantly

I found many of them, repeating the same with different words.

[yosoyfreeman]

Please, edit instead of multiple post. (With this i mean, if you are the last who posted, edit, of course answer with new post to new information :) )

1 is not a bug because clicking on the scene tab allows you to select nodes, it is not expected to bring you to the 3D editor. That's what the 3D Editor bottom is. I may want to click on a node to see its properties, to drag it to the script editor to create a reference, or whatever other reason.

[AThousandShips]

I don't use either Unity or Unreal so I don't know how these work, but other IDEs aren't relevant here as they aren't game engine editors

I see a few reports of users who are confused over some of these things, but they are exceedingly rare, and I should know as I am part of the team reviewing bugs

Having the script editor be detached from the scene makes sense, because scripts aren't specific to a specific scene or node (unless built-in), and workflow is broken by having to switch back and forth a lot, you can see the scene tree which helps you think about the scene breakdown, etc., further it massively reduces clutter, if you have three scenes and five scripts open it'll be very cluttered if it's all unified

I found many of them, repeating the same with different words.

Please list them because I haven't seen any beyond the ones Calinou listed above

[AThousandShips]

From a technical perspective:
Having the script editor a self-contained unit is a big boost, it allows for a lot simpler code and internal workflow, having the scene tab share with other parts that aren't connected with them makes things a lot more complex

The separation of groupings, the "2D/3D/Scripts/Addons/Etc." part, the tab bar for scenes, and the script editor, allows for more of a broad perspective, and also works better on an internals side, currently the scenes tab is directly handled by the part of the editor that handles it and the associated parts, whereas the script editor is self-contained and handles all its logic on its own

This means, for example, that we can entirely deactivate the script editor, and the other parts, the scene tabs, don't have to care at all, no logic needed

The editor is broken down in various docks and areas, which compartmentalises the workflow, each thing in its place, this gives allows for more working muscle memory, like: "I want to edit animations, go down there", or "I want to edit scripts, click that and then there", having more things jostling for space in one area makes this workflow less smooth, it requires you to look more closely, to read and find "oh yes, this tab exactly", it slows down your workflow

For example, though I'm not sure how representative my workflow is, I easily have 2-5 scenes open at any time (any more than that is not really efficient if you're not doing things like tweaking a bunch of different prefabs), and easily 4-8 scripts (more if I use @tool scripts for automation), as well as a few doc pages, if the two tab groups were unified it'd now go from easily manageable even on a relatively narrow screen, to utterly cluttered on even a pretty wide screen, especially with descriptive names (names of just 4-8 characters except for obvious things like "player" is extremely limiting)

[AThousandShips]

Without being aware of certain features and perks of the engine, and the interface aspects required to make them possible, like staying in the script editor when interacting with the scene tree to allow dragging those into the script editor, or just editing in the inspector without having to switch over (especially when, for example, copying property paths, like in the animation player), those quirks can seem like bugs, when instead it's a lack of understanding of how it works

The important step in that moment is to sit back and learn, to expand ones horizons about why the engine does a certain thing even if, with limited understanding, it might seem illogical or counterintuitive

[gamedev-pnc]

First of all, thank you all, guys. Here are similar opinions to my proposal about script/scene navigation and unified list of tabs. I'll quote and tag authors to make the discussion more complete. All mentioned people, you are welcome to join the discussion.

#4081 (comment)

@Exerionius writes:

I can't describe how many times I clicked on a tab expecting it to switch to another script, but got switched scenes instead. It's pretty hard to beat this habit coming from decades working with IDEs. This proposal feels most natural. In the end I switched to using VS Code as a script editor just because of tabs. And even if debugging barely works in VS Code it is still worth it, just because of tabs.

#4081

@Mickeon writes:

Script Editor: Allow displaying Scripts and Docs as tabs above the Text Editor, akin to other IDEs

#4457

@LucidPurple writes:

I find it very annoying that scripts, visual shaders, etc don't use tabs. It makes the most logical sense to me that when you open a script or edit a shader tabs would appear at the top allowing you to quickly go back and forth, they don't.

#7098

@kubecz3k writes:

I think none of those proposals recognized the need of unification whole context switching (not only the ui behind scripts / scenes but also scene tree).
My problem is with how context of the work is being presented, we should have one button that allows to switch context from one subject to another, not only script but also scene (and therefore scene tree)

#1508

(Different proposal, but aiming similar flexibility.) @vitorbalbio writes:

Unify the Panel behavior making all just tabs with the same behavior. [...] Game developers are power users, let us have agency about our screen setup.

#1508 (comment)

@YuriSizov writes:

You can hide the tabs unneeded, can limit what features or even node types are accessible throughout the UI. The only thing that is missing is an easy way to switch between those profiles.

#512

On another page @YuriSizov writes:

I think that Script List is an awful control.

#7732

@Rain-Gayming writes:

Move the things that usually go on the bottom (Tileset/map, Debug, monitoring ect) to tabs like the file system, node, scene and inspector and allow for the freeform movement of them to how users want

#512 (comment)

@Leleat writes:

Instead of doing it as a dock, I suggest doing it like other code editors (for ex. VSCode), where each script gets their own tab. Currently only scenes have tabs

#7838

2nd issue described in my proposal is similar to the one @BdR76 mentions.

godotengine/godot#29722 (comment)

@FrederickDesimpel writes:

I keep having to switch between scenes and scripts and often have to look for the right script, it gets confusing fast.

#3215

@skysphr writes:

If you are editing a scene, the tab will be in 2d or 3d mode. If you are editing a script or a collection of scripts, the tab will be in script mode. Going back to that tab would switch to the editing mode to what you left it.

#1890

@Shadowblitz16 writes:

Want to have tab based scripts windows so you can use the whole horizontal space to code?

#1890 (comment)

@FeatherAntennae writes:

We wouldn't have to differentiate between a few dozen different types of docks, windows, popups, menus, tabs, and views JUST for visually organizing the editor. We would just have a list of windows / views / containers that would really be just floating sections waiting to be either pinned to a "subdivisable container" or popped as its own window that can be "docked" or "pinned" to any of those container in time.

#966 (comment)

@ror3d writes:

When changing from 2d to Script, you suddenly have all the scripts from all the scenes open in the same place. It would make more sense if each scene kept a context of which scripts were open for it, or, even better, get rid of the Script mode and keep scripts in the same tabs as the scenes are. For someone new, this is very cumbersome to get, and it is actually keeping me from enjoying the engine/editor as much as I probably would with a tidier UI.

#5314

@furroy writes:

after decades of using IDEs where the loaded scripts appear across the top of a script panel, I'm afraid I will never get used to this weird way of listing them vertically on the side. I already have them listed vertically in the FileSystem panel right next door if I want them. I found this very confusing when new to Godot, I was constantly clicking the tabs along the top which changed the scene not the scripts even though the editor is in "Scripts" mode and not "Scenes" mode.

---

Not "a few". So:

1. Please keep in mind that these are only people who are not lazy to write feedback. Even more people silently endure the inconvenience or just stop using the editor.
2. Many people think that current interface (script/scene navigation) is not convenient.
3. They would prefer unified tab system. Sometimes they propose other solutions, but still going from the similar point of frustration, showing that current interface does not fit them and needs a rethinking.

[gamedev-pnc]

those quirks can seem like bugs, when instead it's a lack of understanding of how it works. The important step in that moment is to sit back and learn, to expand ones horizons about why the engine does a certain thing even if, with limited understanding, it might seem illogical or counterintuitive

I think this is a somewhat arrogant approach to new users - instead of trying to understand what is convenient for them, too. (It's better "expanding ones horizons", as you say, to understand how to make more people comfortable in Godot.) New users do not have to guess that non-functioning tab buttons, complicated navigation with multiple levels of nested tab lists, or absence of classic shortcuts is a carefully thought out design. Unfortunately, they may get the first impression that the interface is not professionally designed, that it doesn't support basic principles of the UX, and such people will close the editor forever. I wouldn't want that, and you wouldn't want that. That's why I'm sharing my opinion and trying to address those issues.

Even if there should be "a single best workflow that fits them all", current interface doesn't communicate that workflow in a clear manner.
I think that current interface (scene/script navigation) must be changed:

1. to allow more different workflows (this proposal)
2. or, as a compromise, at least to make your single workflow to read explicitly.

[AThousandShips]

Several of your quotes are misrepresentative of the views of those involved, they do not necessarily agree with you or think the same, you see that easily but reading the context

[gamedev-pnc]

Several of your quotes are misrepresentative of the views of those involved, they do not necessarily agree with you or think the same, you see that easily but reading the context

Again, as I said above: many quotes show that "they would prefer unified tab system. Sometimes they propose other solutions, but still going from the similar point of frustration, showing that current interface does not fit them and needs a rethinking".

[AThousandShips]

Except most of these aren't the same idea as you present, for example not:

• Script Editor: Allow displaying Scripts and Docs as tabs above the Text Editor, akin to other IDEs #4081 (comment)
• Script Editor: Allow displaying Scripts and Docs as tabs above the Text Editor, akin to other IDEs #4081 (This one literally talks about wanting to keep the scripts separate, just to have them horizontal, no actual change made to the system itself)
• Unifying Scene and Script Tabs to reduce UX ambiguity #7098
• Move Script List to docks #512

They ask for other ways that do not merge scene and script tabs, further you mix both having a unified tab system with those wanting different behavior when clicking nodes, that's muddying the waters

There's nothing arrogant with saying "you are missing the point of why this works this way" when you suggest removing a feature that exists for a reason and is helpful

But again, these are still actually just a few, and most are comments, not proposals (as that what was I was talking about and asking for), and the general support for these are not good generally, many have far more or comparable down votes to up votes, so the changes are not popular

If there was a broad support for this then that'd be a different situation, but adding alternative layouts or setups when that isn't widely demanded isn't a worthwhile way to spend resources

[YuriSizov]

Well, since I was quoted I would like to expand on my position. I think that there are a few issues with the current UI, and they did hinder me at first. I have more experience with coding tools and they all feature a single tab bar for everything being edited, be it scripts, text files, binary resources, database tables, etc. I like that approach in coding tools and I find it intuitive.

That does not mean to me that we ought to do the same in Godot. Godot relies on inspectors, docks, and other editors a lot. It already moves things to the sides and to the bottom of the main view. This allows users to be proficient at editing multiple things at once this way. And I think for every one who doesn't find it intuitive there is at least one who does.

Moving everything to tabs would go against basic UI/UX principles of the Godot editor. It may make it better for some, but it will also definitely make it worse for others. I don't think we want that. We shouldn't do a rugpull from under the existing Godot community. Instead we should do more graceful, targeted changes.

I would rather we got rid of the scene tab bar entirely than mix it with something else. I would rather we moved scene selection to its natural place — the scene dock. I would rather the script list was moved to a dock as well, since it takes a lot of valuable space in the script editor on smaller displays (I have a whole graphic in one of the proposals about that). These are the things I would do to address my issues with the current system.

I have actually made plugins for these changes and used them for many months when working with Godot 3 on my projects. They worked great for me, though the API available didn't allow me to fully port some of the features.

I do not support this idea of unification.

[AThousandShips]

I agree that dock a based system would be much better use of screen real-estate, tabs stored horizontally take up so much more space, and scrolling in them is much less intuitive

[gamedev-pnc]

One must distinguish between a problem and a solution. Proposed solutions sometimes are different (as I already said earlier), but they indicate the same or similar problems.

@YuriSizov can support another solution, but clearly he states: "I think that Script List is an awful control". It's part of a problem that I try to get attention to.

I provided links, so everybody can check what people say and in what exactly contexts. Everything is fair.

No matter if opinion is formed as a proposal or a comment. Those are still opinions of Godot users - that's relevant.

[AThousandShips]

Yuri just commented here himself so no need to speak for him

[gamedev-pnc]

Quotes speak for themselves.

[AThousandShips]

If you are going to continue speak for people when they comment on a proposal clarifying how they don't agree with you then I can't take your approach to this process seriously

Have a nice day, I've been trying to express why the system works like it does, and that it's popular, and especially that your suggestion isn't a popular one

Please respect when people say they are stepping away from a conversation, tagging them to get their attention when they've declined to continue to engage with you is rude and inappropriate

I repeat, have a nice day

[gamedev-pnc]

@AThousandShips, so you ignored provided quotes and opinions. You may dislike my proposal, but ignoring a problem (which Yuri tries to address, too, just in a different way) is not serious. Problem remains.

[gamedev-pnc]

This is in fact a great point, as it is know fact that people who are unhappy about something, tend to be a lot more vocal about the issues than people who are happy.

No, it's about "Sales Funnel", a well-known model of user activity. For every one who actively discusses the problem, there are more people who silently agrees, but isn't motivated enough to express the opinion.

Would be interesting to have in-editor polls "vote the editor overall" or "vote this new feature". That's another proposal though. )

[kubecz3k]

Since I was mentioned I will give my two cents, I do not think current approach is the most optimal one I have a lot of problems with it and I'm using Godot since it became public, for me it would be the best to pursuit approach from #1935 with some UI support for it

That being said this is sensitive topic everyone is using editor in a different way and there has been a lot of discussions around this part of the UX. I think the best we can count on is to expand plugin API to the point which will allow us to integrate various approaches in a way which would be stable and making an impression of build-in behavior, I also think there would not be much opposition towards providing missing parts of such api we just need to identify parts which are missing and have someone determined enough to implement plugins that work the way they want them to

[YuriSizov]

Let's not delve into quick-chatting here. This repository is a discussion forum, and for a more interactive dialog I invite you all to the Godot Contributors Chat.

@good-gamedev Let me put things into a bit of a perspective. Proposals are about both the established problem and the proposed solution. People disagreeing with your proposal may disagree with the problem itself, but it's not a given. In this case, I don't think there is a lot of disagreement with the problem. But there is with the proposed solution.

Quoting people who also agree with the problem is useful, but they don't support your solution automatically. In fact, in many quoted cases alternative solutions are offered and supported. I understand that you wanted to dispute the claim that most people are happy with the current UX. I don't think it's possible, since, as mentioned above, happy people would rarely voice their happiness about stuff like that. They will simply use it.

But that's fine, we can work with those unhappy few who have voiced their concerns. We just need to find a solution that doesn't face backlash and can get to a consensus.

[gamedev-pnc]

@YuriSizov, I agree with that. Thank you for your feedback.

[gamedev-pnc]

the best we can count on is to expand plugin API to the point which will allow us to integrate various approaches in a way which would be stable and making an impression of build-in behavior

It would be great! @kubecz3k, thanks.

[vitorbalbio]

I was quoted here. My proposal was quite different but I do think it would be okay to have an "Everything is tabs" plus "Every tab is detachable" approach just like many other software. This seems to be a good starting point to increase flexibility and familiarity for newcomers. What kills the UX in Godot is the lack of consistency so any proposal that tries to unify panel behaviors has my approval. The problem cited here is that it would occupy a lot of space is true but I think it's a plague in all the UI with A LOT of unnecessary spaces and padding and margins so should be treated separately as a UI problem.

[gamedev-pnc]

Because of all mentioned issues I decided to minimize usage of Godot Editor.
Instead I configured Visual Studio Code, plugin "godot-tools" works well.

Moving part of the workflow to an extern editor doesn't add a "unified tab list", but it helps to overcome mentioned issues:

1. Technically all tabs are visible and accessible on 2 monitors now (scene tabs in Godot Editor, script tabs in VSCode). So no more switching to a Script Editor (from Scene Editor) to access a hidden script list inside.
2. No more confusing unresponsive scene tab buttons, since Godot Editor is always in Scene Editor mode for me now.
3. In this workspace Ctrl+Tab and Alt+Tab provide a fast navigation and context switching between two last "tabs" (be it a script-to-script, script-to-scene or scene-to-script).
4. etc.

For everybody interested how to configure Visual Studio Code for Godot project:

• https://www.showwcase.com/show/34429/effortless-scripting-in-godot-4-with-visual-studio-code-a-step-by-step-guide
• https://github.com/godotengine/godot-vscode-plugin#gdscript_lsp_server_port
• Unable to launch debugger with Godot 4 (workaround included) godot-vscode-plugin#389 (comment)

---

I understand that old-timers are accustomed to a certain interface, which is why resistance arises. They can disagree with my solution, but I was surprised that some people here even denied that problem exist. At least I (and many other mentioned people) have attracted additional attention to UX problems again.
I hope that someday Godot Editor will become a convenient tool for more people. "Waiting for Godot" exactly. 😄

Thanks again to all participants of the discussion. :)

[gamedev-pnc]

More critical quotes about noted UX problems in Godot editor, regarding tabs and script panel:

https://www.reddit.com/r/godot/comments/13k101v/it_always_seems_janky_to_me_that_you_edit_all/

Epsilia: Yep. It's always confused me. I moved to do my scripts in VSCode instead.

RomMTY: This is the reason why I switched to vscode almost immediately.

ExdigguserPies: See this is the crux of the matter. The tabs should give context. That's how tabs work in any program - the tab dictates what you see because it gives context. But in Godot editor, all the scripts you have open are shown under all the tabs, even if they have no context within that tab.

Hydraccion: The built-in script editor is not great in general. Now that Godot 4 supports multiple windows, I hope it becomes detachable at some point, that would be amazing. Having to constantly switch between the script and scene is one of the main reasons I started using an external editor.

golddotasksquestions: The first thing I do when I download Godot fresh, is to hide this panel. It the most irritating thing and just needlessly takes up precious horizontal space! I then navigate scripts by opening the scenes I'm interested in and clicking the little script icons next to nodes. This way I always know "where I am" and what script of what node I'm editing. Before I changed to this workflow I wasted a lot of time thinking instead of doing and even more cleaning up my own mess because I once again edited the wrong script!

PopeOh: Whenever I start to overthink the UI design in one of my apps I remember that the engine editor gets away with such a crazy UI decision. The scene tabs should not be visible when in the scripting view. Alternatively the scripts should also be tabs at the top.

YetAnotherRCG: I have been using the editor routinely for about 3 weeks at this point and this is still triping me up regularly

dagbiker: I think it would be less confusing if there weren't four tabs on the top, two of which are "views" of the current scene and then you have the code, which really should be separated somehow from the 3d and 2d tabs.

H2olt: Everyone structures their thinking in their own way, I greatly prefer to be able to see both the scene view and the code simultaneously. There does not seem to be any reason that the layout is locked down as much as it is. Truly feels like one of the limitations that keeps this software from feeling more professional.

EamonnMR: This UX is beyond clunky. No ryme or reason. Back/forward and grabbing the thing I want directly from the file tree are the only functional ways to navigate to a script. Really thought, what I want is a split-screen view so I can edit two files at once. I think they would need to detach the script editor from thr scene editor a bit more to do that.
EamonnMR: the editor is always in a scene tab, even when editing a script. That's why the UI here is janky.

Noisebug: Lots of confusion with this and why I use any other editor because Godot doesn't work like the traditional VSC/Jet/Vim tools. Yes, VIM, has tabs on top like the rest of em. :D

https://www.reddit.com/r/godot/comments/16l1qg0/godot_4_code_editor_and_filter_scripts_can_be/

BdR76: However there is one thing I find hard to wrap my head around, and that is the way the code editor IDE is setup. When switching between scenes, I've often found myself editing the incorrect script file.

MrFlamey: I've also made mistakes while switching scenes and think the design is a bit confusing.

https://www.reddit.com/r/godot/comments/fc5cka/open_scripts_as_tabs_in_the_top_bar/

GlobalF: I find the vertical list of scripts confusing, is there any option to open scripts as tabs along the top tab bar (even if that script is not part of a scene) and disable this vertical script bar
my brain can't seem to get around the idea of having two dimensions of open "things"... I constantly find myself looking in the top bar for a previously opened script and having to take quite a few seconds to hunt down the script I am looking for

Avtem22: Yeah, the navigation between scenes is very confusing to me as well. i wish they'd remake it so it wouldn't be that confusing

cloudliusihui: It's so confusing. Why they cannot just use the design principle like any other IDE or browser where middle click to open it in a new tab while middle click the tab to close it

#9034

tektrip-biggles: Godot's UI is often extremely inconsistent & can be confusing
<...> I'd propose there be a single unified tab bar running the full width of (each) Godot window which can contain any number of different kinds of tabs.

#8819

starry-abyss: Currently scene tabs work in a confusing way (or don't work at all) when the script editor is open.

#4582 (comment)

ssokolow: In short, Godot's navigation feels like a mess of three overlapping "tab bars" that interact in unpredictable and confusing ways, when the user intuitively expects them to have some kind of hierarchical relationship to each other, made worse by a mismatch between where Godot's UI draws the line between different "apps" and where the ecosystem at large does.
<...> It's a reminder that there's no "address bar" or other single thing you can trust to always unambiguously tell you where you are in virtual space and provide a means (even if it's just copy-pasting a URL) to feel confident in your ability to return to places you've been.
<...> All this non-orthogonality between the 2D/3D/Script/AssetLib tab bar, the scene tab bar, the scene tree, and the de facto vertical tab bar on the left of the script editor is like a cognitive version of This is malformed HTML.

https://www.youtube.com/watch?v=p2Qr9jsmp74&t=2495s ("Waiting for Blue Robot: The Ultimate Guide to Godoverse")

Pretty much sums up my impression:

but the editor is horrible... and he was so positive about it... He really liked it. We were like, how can you work with this? Yeah.

[Mickeon]

Why did you feel like closing this proposal, even though you have more to discuss? Doing this makes the proposal harder to discover and gather further feedback for it.

[gamedev-pnc]

Some people in this thread denied the problem per se and its relevance to a large number of users. It was stated that UX bugs are not bugs, and that currently supported workflow is ok for them. This discouraged me from actively diving in the Godot engine development. Today I saw more opinions similar to mine and spontaneously decided to write a summary for clarity. Let it help the next adventurers in their proposals. My proposal was closed though.