Redot-Engine / redot-proposals

Redot Improvement Proposals
MIT License
29 stars 7 forks source link

Code Editor with Tabbed and Multi-Script Support #14

Open digimbyte opened 2 weeks ago

digimbyte commented 2 weeks ago

Tested versions

always present

System information

windows 10 - godot 4.3 stable

Issue description

Issue Description: The current Redot Engine code editor integrates scene content and code editing in a single view, which leads to confusion, accidental clicks, and even lost work. Developers working on multiple scripts and scenes simultaneously are hindered by the lack of flexibility in managing code windows and tabs.

The proposed feature requests the following improvements for the code editor:

Benefits:

Steps to reproduce

Open multiple scenes and code scripts in the editor. Try switching between different scripts while editing the scene.

Minimal reproduction project (MRP)

N/A

GordofTheSandAgedPrince commented 2 weeks ago

I was surprised when I first started using Godot that this was not a feature.

darkhog commented 2 weeks ago

There's an addon on AssetLib (Script-IDE) that fixes script editor so it has tabs, but yeah, it should be a basic feature.

AlexMGitHub commented 2 weeks ago

I'll chime in to add my support for this idea. Side-by-side scripts is something that would substantially improve the user experience. I switched to an external code editor for a while because navigating back-and-forth between scripts inside Godot was a pain, but found the external IDE to be clunky and eventually sucked it up and moved back to writing my code in Godot.

Adding tabs and side-by-side scripts is a feature that would immediately and substantially improve the user experience for all Redot users. I think it also demonstrates that Redot will focus on things the developers actually want and need.

I haven't used Script-IDE, but from the description and screenshots it doesn't appear to support side-by-side scripts.

digimbyte commented 2 weeks ago

additional context, conversations have brought up custom work spaces with modular windows/tabs if that is a primary focus, that would speed up this feature as well.

since we would likely have a main code window, main scene window, which behaves as default locations for tabs to open into of which dragging tabs to other locations create child views, or minimum split view

Visnicio commented 1 week ago

I didn't understand yet what is being proposed here, it's like, a rearrangement of the UI?

There's an option to stay in script, could this help you? image

Visnicio commented 1 week ago

Here is a example of the current behavior

stayinscript

GordofTheSandAgedPrince commented 1 week ago

I didn't understand yet what is being proposed here, it's like, a rearrangement of the UI?

There's an option to stay in script, could this help you? image

It’s to have multiple scripts open at the same time. To make things like the script editor a window if you are using 2 monitors or want to rearranged however you like

gamedev-pnc commented 1 week ago

I absolutely agree that current editor interface leads to confusion, it has UX bugs. Tabbed and Multi-Script Support can be implemented in the classical way:

  1. Script, scene, doc page, etc. - they all are tabs.
  2. Optional screen splitting.

Here's an example how tabs+splitting looks like in Visual Studio Code: 2024-10-03 22_02_48 - ● Type doc page - Visual Studio Code (We see horizontal and vertical splitting, all three spaces can have multiple tabs of any type.)

2024-10-03 22_22_09 - Script1 - Visual Studio Code


Some developers are used to the current engine's editor interface, but many find it confusing (see below). The point is - current interface has UX bugs and is very restrictive, meaning that it supports only few specific workflows. It can be convenient for some people and not convenient for others. Instead:

  1. "Everything is tab" + "Optional split" allows organizing and combining contexts (scenes, scripts, etc.) in any desired flexible way, supporting many possible workflows, everything that fits you best. One can split tabs by their type (e.g., scenes to the left, scripts to the right). Or work without splitting, just open scene tab and script tab and move back and forth with Ctrl-Tab. Or open Multiple Scripts Side by Side. Etc.
  2. Tab/split interface is the well-known approach and corresponds to the classical UX principle of least surprise: https://en.wikipedia.org/wiki/Principle_of_least_astonishment This is important, especially for new developers.
  3. Currently editor has multiple levels of tabs (2d/3d/ScriptEditor, scenes, scripts). "Everything is tab" simplifies interface (only one level of tabs) and removes extra cognitive load while navigating in the editor.
  4. Unification "Everything is tab" simplifies creation of plugins.

Let me justify my criticism of the current interface and the need for changes. Here are critical quotes about UX problems in Godot editor, regarding tabs and script panel. This summary shows that the problem exists and it is relevant to a large number of users.

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

2024-10-02 10_39_55 - It always seems janky to me that you edit all scripts under the tab for any scen

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

https://github.com/godotengine/godot-proposals/discussions/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.

https://github.com/godotengine/godot-proposals/issues/8819

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

https://github.com/godotengine/godot-proposals/discussions/4582#discussioncomment-3017854

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")

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.

AlexMGitHub commented 1 week ago

@gamedev-pnc Your post is the definitive mic-drop on the subject. Thanks for your input!

do-sieg commented 1 week ago

I've been switching back and forth between the script editor and VS Code. The Script editor has improved a lot over the last months but this is the main reason today (apart from version control management) I tend to open VS Code, when I need to see two scripts side-by-side. Other people have mentioned the time wasted to navigate from script to script. Even going back to the previous script you had opened is a mess.

darkhog commented 1 week ago

Yeah, having two scripts open side-by-side would be amazing. Though I feel like we shouldn't make this "just" for script editor. Instead, a more in-depth rework of the entire editor UI should be considered so that you could move panels, etc. anywhere you want just like you can in Unity or Unreal. That way, you could have two script editor instances open side by side, each displaying different script. Or two scene windows, each with a different scene open.

digimbyte commented 1 week ago

at the core, the concept is about removing the script vertical menu and converting it to tabs. if any menu is still to persist, it would be a separate workspace to the node navigation as they serve the same purpose for different workspaces

if we have modular workspaces, it would make this request redundant but that change maybe too extreme to push this early

zaftnotameni commented 1 week ago

I'm extremely against investing time/effort in the builtin code editor, instead encouraging people to use proper mature editors (vscode, neovim, visual studio, jetbrains, zed, whatever people prefer).

Visnicio commented 1 week ago

@zaftnotameni the built-in editor has some features tailored specific for the engine, such as drag-and-drop nodes or resources from the file system into the code-editor.

I f*ing love JetBrains Rider for coding, but I miss dragging my scenes from the file system into the code instead of writing the full path from memory

zaftnotameni commented 1 week ago

@zaftnotameni the built-in editor has some features tailored specific for the engine, such as drag-and-drop nodes or resources from the file system into the code-editor.

I f*ing love JetBrains Rider for coding, but I miss dragging my scenes from the file system into the code instead of writing the full path from memory

ctrl + shift + c copies the path for a node inside the scene and you can just use that to paste directly at your ide of choice

i agree that's still not NEARLY as good as drag and drop, that functionality specifically is really nice, but there's a real tradeoff there

digimbyte commented 6 days ago

@zaftnotameni the built-in editor has some features tailored specific for the engine, such as drag-and-drop nodes or resources from the file system into the code-editor. I f*ing love JetBrains Rider for coding, but I miss dragging my scenes from the file system into the code instead of writing the full path from memory

ctrl + shift + c copies the path for a node inside the scene and you can just use that to paste directly at your ide of choice

i agree that's still not NEARLY as good as drag and drop, that functionality specifically is really nice, but there's a real tradeoff there

I never knew about that, perhaps that should be an issue or PR? add copy options to nodes with right click in resources: copy global path in node inspector, copy relative path + copy resource path

zaftnotameni commented 5 days ago

ctrl + shift + c copies the path for a node inside the scene and you can just use that to paste directly at your ide of choice i agree that's still not NEARLY as good as drag and drop, that functionality specifically is really nice, but there's a real tradeoff there

I never knew about that, perhaps that should be an issue or PR? add copy options to nodes with right click in resources: copy global path in node inspector, copy relative path + copy resource path

i think all cases you mentioned are already the current behavior, am I missing something?

zaftnotameni commented 5 days ago

Disclaimer: bear in mind, i'm speaking here as myself, not the Redot team. Don't take anything that I say is wrong as a decision from Redot to not fix it.

I would like to split this criticism in multiple parts.

digimbyte commented 4 days ago

People moving away from the builtin editor into vscode/vim/etc: GREAT, the more the merrier, I encourage 100% of users to do that. Maintaining an editor will always end up with a subpar result because an editor is in itself an extremely complex project, if you need a proper editor go use a proper editor.

main issue with VS code or any other editor is IDE support for highlights and syntax correction and formatting which is why its suggested to look at other languages for a wider support

UI not letting you show things side by side, overall layout being stiff and not allowing real customization other than the 2 (small columns) 1 (big view) 2 (small columns): flat out something that should be improved, not really just related to the code editor.

this depends on a workspace overhaul, its talked about in the comments, no PR or issue has been provided at the moment but really should be its own thing