Improved Dock System

[reduz]

Note: I opened this proposal for everybody to bikeshed on it as much as they want. Big changes are unlikely to happen before 4.1 anyway, so there is plenty of time to decide on things.

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

While for the most part it works well, there are some limitations with how the Godot dock system works. As an example, the following use cases are requested but are not currently possible:

• Move filesystem to the bottom, similar to Unity.
• Move shader editor to a side.
• Ability to separate script editor from viewport editor.

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

For the most part, for most of the use cases, the Godot system works well. The contextual editing does it job and ensures users are not lost in the hundreds of editors available for different types of nodes and resources. This happens because the one you need always comes up in your aid at the right time.

A system more similar to Blender o Unity is often proposed, but Godot just does not function the same. There are no clear workflows and there are too many contextual editors. Those systems also can get messy fast.

The solution, in my view, should be more conservative and focus on expanding what we have to cover the missing use cases rather than changing it for other approach.

As it stands, Godot has now two types of docks:

• Side Docks
• Bottom Panels

They can't be exchanged. This makes sense for the most part because most things in the bottom panels (console, debugger, animation editor, tile editor, polygon editor, etc) would simply not function on the side. Likewise, most docks on the side ( such as inspector, scene tree, node menu) would not work on the bottom. Additionally bottom panels have the benefit that they can expand over the Viewport if necessary for more editing intensive operations (such as animtree or visual shaders).

The exceptions are few: Filesystem dock would work well on the bottom, and shader editor could work well on the side (given a big enough monitor). Not a lot more, though.

To achieve more flexibility, some changes would be needed:

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

The following would need to be changed:

• Debugger, console, animation editor, shader editor (which should allow multiple shader editing at some point, and allow mixing of visual and text shaders, like the script editor) and audio bus editor should become docks.
• The bottom panel should still look different than the side docks, because you can collapse the panels to gain visibility and expand them (respect to the viewport) when you need to use them (or when a contextual editor needs to pop up). Keeping this distinction is important. This way, visually, there should be not any change in respect to what we have now.
• Contextual editors like Tile Editor, Polygon Editor, Animation Tree Editor and many others (which only one should open at the same time and only when the node or resource is being edited) should still remain hard-coded to the bottom panels and not considered docks (you can't move them), so they keep popping up exactly when you need them.

Additionally, I think an extra docking position at the bottom should be added (that is just for docking, cant be folded and can' t be expanded towards the Viewport, so this is effectively another dock position and not a panel), in case you want some editors to persist 100% of the time there and never collapse, like filesystem or animation editor (and again, contextual editors can't move there and still remain in the bottom panels below the Viewport):

The other area that should be addressed is the 2D / 3D / Script / Asset Lib, etc. I do not think they should be regular docks and I think they are fine as they are, but there are some exceptional cases that need handling, specially in regards to the script editor:

• Ability to put the script editor in a separate window.
• Ability to put the script editor side by side with the Viewport.

That said, this comes with cost, however. While having a script editor integrated to the main UI is very useful, having it open together with the 3D viewport will cause it to have worse performance. If it goes below the monitor refresh rate because 3D is also rendering, script editor will feel clunky and there is no workaround for this. Godot will have to detect that editor is rendering below the refresh rate and put a warning in the script editor that editing is sub-optimal because the 3D window is taking too much time to draw.

Well, maybe there could be a work-around, we take a screenshot of the Viewport and show this when the text editor is focusing for inputting text (if there are animations, it will freeze), but it will require clever thinking on the usability side.

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

N/A

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

N/A

[Zireael07]

I don't recall anyone wanting to see a viewport while scripting (or at least not live updating viewport, so the usability problem could be worked around by just not making the viewport update while script editing)

However, this proposal is missing one thing: side docks really need the ability to be collapsed/hidden. Most urgently for the Android version, but I have the issue of the main portion being too narrow EDIT: on desktop too if I downsize the Godot window in order to check a tutorial/some code at the same time (or try to put website/Godot side by side)

[reduz]

@Zireael07 that is interesting, guess on smaller screens that is becoming more of a priority.

[OuTopos]

First of all, Godot is awesome, love it. These are just my opinions on what I believe would improve Godot.

The contextual editing system means well but in practice it can be a bit cumbersome.
For example let's say I'm editing a shader, I remember I need to change some node value or simply check a value. I select the node in the tree and the shader editor is gone. Now I have to spend clicks/time to get back to it. I would prefer to be able to keep the shader editor exactly where I chose to have it and I don't want anything closing it for me.
That goes for most other bottom panels.

It's a bit better with the Viewport and Script editor since the tab is always there. But if I use the script editor and I just want to change a value on a Spatial/Node3D I will be taken to the 3d viewport when I select the node in the tree. And then again I have to click my way back to the script. Like I said in this case it's less bad since you always have the tab and a hotkey.

I like to think that a ground rule is to do less automatically when it comes to UI. Don't move things around or close them for me. Let me be in control.

There are so many possible configurations that might benefit people.
People have different aspects ratios, different screen rotations, different number of monitors and different preferences.

Sticking to the Side Dock and Bottom Panel mantra is the wrong way to go if you ask me.

As a disclaimer, I have no idea of technical and performance limitations, this is purely from a design and workflow perspective. I also understand that this would have a big development cost and might not be feasible due to that.

[StefanJanssen95]

I mostly work on a portrait oriented monitor when I'm programming. For Godot I usually have to rotate my monitor to a landscape orientation.

I've always used Unity, which facilitates in my work flow. I made the switch to Godot half a year ago. It works great in landscape mode but as someone who has worked in a portrait mode for years (and still do when programming anything outside of Godot) it has been a major hurdle to overcome.

Having the possibility to fully customize dock locations would help me a lot, but I do think that I'm a minority when it comes to portrait monitors.

[Janders1800]

The exceptions are few: Filesystem dock would work well on the bottom, and shader editor could work well on the side (given a big enough monitor). Not a lot more, though.

I have a couple suggestions assuming a 2 monitor setup.

I agree about the Filesystem.
About the shader editor I think it can be integrated in the script editor, as long as the script editor can be on its own window, shaders can be managed like normal scripts.

Output, Debug, etc, can also go in the script editor window.

I won't make suggestions for 1 monitor setup since I do no work that way.

[eon-s]

A redesign of this type may take a lot of time... and it may need to take into account modern needs and platforms (now with android support it needs to be designed to be more touch-friendly).

I don't mind the current disposition (but not the limitations for the locations of some types of docks), some docks can be contextual and "folded" too, like Inspector and Node panels which need a node or Resource selected (also Import dock).

Something really needed is the ability to have more than one dock of the same kind opened, on other tools it is common to have an inspector pinned on an element and another free to compare, for example (during edition and debug).

Ah, and the script editor, the ability to "undock" it would be cool (particularly for plugin and tool makers), maybe the script editor can be a separated module from the visual editor, if that makes sense.

[nonunknown]

Was talking with friends yesterday, if we could for example get the game window and merging it with the editor would be so cool:

I mean is that the game opens, but you can throw the window inside the editor, and then you can easily see the remote tree without getting the game window to hide behind the editor window!

[theMotionblur]

Hm. I guess this isn't exactly about docking but more a fringe case that stems from the more fixed positions of Godot's editor Windows. So far the two things I've encountered that I don't like in regards to "popping up when needed" are two things and they are pretty much opposite to each other.

Sometimes I'd wish the code panel was pinnable so that the view did NOT change when I click on a node in the tree. This might go away with more experience but for example when looking up attributes on a node for scripting I find myself having to click the node I want to look up what an attribute name or current values etc. but then the Script view changes back to Scene view mode. Making that pinnable would someteimes be cool if there is no way to split the Code from the scene view.
Splitting instead of having only one would of course be preferred but if I read that correctly that doesn't work, for now.

previews for textures, anims or audio when selected in the FileSystem dialog on the other hand do not pop up fast enough, IMO. Or even more so - the default view of the inspector is to the right of the Scene View, which feels good to work with in most cases. Yet after previewing an audio Clip it appears in the lowest bottom of the Inspector. Which means having to move the mouse over and click the opposite side of the screen. Bitmap previews only appear on double klick and also make the eyes look on the other side of the entire screen by default.

What would be cool: If the preview for media at least was splittable and freely moveable, preferrably close to the browser of the filesystem or maybe to the output/debugger/audi/anim window. Or maybe a window that can be positioned freely....

I fully admit that I don't have a full proposal for this yet. It's just one of the most prominent things I've noticed in regards to the rigidity of the program windows, over the last few months.

[Calinou]

Sometimes I'd wish the code panel was pinnable so that the view did NOT change when I click on a node in the tree.

You can hold Alt while clicking on a node in the Scene tree dock to prevent the main screen from changing.

[justinbarrett]

I don't recall anyone wanting to see a viewport while scripting (or at least not live updating viewport, so the usability problem could be worked around by just not making the viewport update while script editing)

However, this proposal is missing one thing: side docks really need the ability to be collapsed/hidden. Most urgently for the Android version, but I have the issue of the main portion being too narrow if I downsize the Godot window in order to check a tutorial/some code at the same time (or try to put website/Godot side by side)

I would like the live update feature...we all have to remember...a comment like this, or mine even, does not reflect what everyone wants. I think it would be nice to have it a toggle..."enable live updates"(on/off)...just my take.

[Zireael07]

@nonunknown: Your comment is essentially a dupe of another proposal (the one about live game preview in editor). It was attempted at least once but the PR got stuck/stalled IIRC

[thimenesup]

I think that the idea of "hardcoded" docks should be discarded, since I believe that it results in arbitrary restrictions, as a matter of proof it IS possible to have the FileSystem at the bottom dock. Ideally I think that every "dock" should become a freeform window instead, which can be arbitrarily moved and parented/attached/anchored to a position, it should also have the benefit of actually making an exclusive window for said dock, would be really useful if you have multiple monitors.

[nonunknown]

Your comment is essentially a dupe of another proposal (the one about live game preview in editor).

nope its not live preview, this is another thing, its just about docking the game window inside editor, nothing more!

[Zireael07]

docking game window inside editor

This is essentially what that other proposal is about, getting rid of game window being separate

[marciodrosa]

Having the script editor side by side with the viewport was never a thing I miss.

However, I always though it was weird the 2D / 3D / Script buttons above the viewport. I never got used to it. I mean, the 2D / 3D makes sense I think, but in my opinion each script should have their own tab (the same way each scene has). It also eliminates that problem where the viewport would reapear when we click a node. But, like I said, I don't see the necessity of open it side by side with the viewport. Maybe it is useful, but not as much.

[Janders1800]

I have a couple suggestions assuming a 2 monitor setup.

A couple of images illustrating my comment.

Monitor 1

Monitor 2 (Shaders are handled as normal scripts here)

[SirLich]

Have fun bike-shedding but make sure to read it well first before going on "I think it should work like Blender/Unity/etc"

I don't think this is a topic you can deflect!

Having "contextual" windows that appear/disappear without my input is something that I dislike about Godot. I know it can be annoying to constantly be suggested, but it feels wrong to me to iterate on the docking without also exploring that issue more properly.

As has already been brought up in this thread, it takes loads of clicks to open shader editor in some contexts:

• Select Node in Scene
• Click on the Shader Material
• Click on the Shader

Now click on the viewport. Boom, shader editor is gone.

I just don't see any defensible reason not to have a tabbed editor system.

[reduz]

@SirLich That is a different problem actually, which is that a lot of editors are transient (attached to what you select) when they should not be. That will be solved soon.

[andyp123]

Godot will have to detect that editor is rendering below the refresh rate and put a warning in the script editor that editing is sub-optimal because the 3D window is taking too much time to draw.

Unless the game is running, you could selectively update the 3D view. This is what Unreal does, and it actually has a toggleable real time mode, so you can preview all your effects and shaders animating in a level, or just turn off the update if you don't want it to be a drain on performance/battery. It then updates only when you interact with the viewport or change something.

With regard to tabs, I really found the way that the script and viewport share the same tab extremely confusing, since the tab name is always the name of the open scene, but you can change to a different script and it will still show the scene name in the tab. While I'm not sure an open tab per script would be great, I do think at least giving the script editor it's own tab that shows the current script name, and giving tabs an icon for the editor type (2d, 3d or script) would remove some of the confusion.

Also, minor suggestion, but I suggest changing the default editor view switching shortcuts so that the number lines up better with the view/editor type would make more sense. Ctrl+F1 for script, Ctrl+F2 for 2d and Ctrl+F3 for 3d makes more sense from a numbering perspective.
Personally, I have a 60% keyboard with no F keys, so I use alt+1, alt+2, alt+3, which also seem more comfortable to press.

[RabbitB]

I know this will be hard to describe accurately with words alone, so I can edit together a rough mockup tomorrow when I have time, but personally I'd like to see a combination of Windows Multi-Desktop, the accompanying window selection view and panel docking. That is, I'd like to hit an easy key combination, which will take me to an exploded view of all relevant panels (viewport, script editor, file-system, animation dock, etc.) and a list of "desktops" or in this case, different editor layouts. Not much different from what already exists in Godot, except visualized and easily swappable between.

For the sake of this explanation, I'll just call everything a panel as my idea wouldn't require a distinction between docks and panels. Anything can be in whatever orientation the user desires.

Whichever layout is currently active is editable by dragging and combining the panels available. If I have an ultra-wide monitor and want a tri-pane view of Viewport, Script-Editor & Shader-Editor, then I can just drag those three panels together. Panels should auto-dock to each-other when dragged together and resized by snapping to fit. As-in, if I have those three panels side-by-side and I drag the output console to the bottom of them, it'll automatically resize to be the full width of the window. But say I want two separate panels on top, then I can drag one and it'll resize to the full width, but adding a second to the right of it will cause them to split the width and each take half the total width of the window. If I want one larger than the other, then I can manually resize the width of a panel like you would a normal UI window.

Having this layout editor combined with selectable layouts means the user doesn't have to put together a couple different layouts that try to do too many things. They can have many dedicated layouts that focus on individual tasks. For instance, a shader-editing layout that's just the shader-editor, the inspector and the viewport. Absolutely nothing else to take up room. Another example is animations. I find I develop 2D animations in two-different ways. One where I animate with the viewport and animation-editor and another where I animate using just the inspector, script-editor and animation-editor. This would allow me to easily have both and swap between them almost instantaneously.

The name of the game is maximizing usable space by removing absolutely everything that isn't needed in that moment. For panels that may still be necessary but aren't needed all the time, they can be marked as collapsible. This would allow for the likes of the output console to still be included in a layout, but still only expands when relevant and stays collapsed otherwise.

[ngreve]

A system more similar to Blender o Unity is often proposed, but Godot just does not function the same. There are no clear workflows and there are too many contextual editors. Those systems also can get messy fast. - reduz

Do you mean the actual code base necessary for such a system gets messy or do you mean just user interface wise? I often feel Godot does too much hand-holding regarding the UI and that it limits itself because of this. So, I am one of the "do it like Blender" guys.

Just like thimenesup already said:

I think that the idea of "hardcoded" docks should be discarded, since I believe that it results in arbitrary restrictions

But ok, if you do not want to go this route here are three things which annoy me the most:

• Not being able to have the script editor and the 3d/2d view open side-by-side (already in the OP)
• No vertical/horizontal splitting in script editor
• Not being able to have the script editor and the built-in help open side-by-side

I don't recall anyone wanting to see a viewport while scripting (or at least not live updating viewport, so the usability problem could be worked around by just not making the viewport update while script editing) - Zireael07

Having the viewport side by side with the script editor is very useful when working with @tool scripts. Maybe I misunderstand "viewport update" in this context, but if you would not update the viewport, you would make the side-by-side view useless again. Why showing the viewport when its content doesn't represent what is happening in the scripts. So, the viewport should be refreshed/updated based on the edited (@tool) scripts.

[RabbitB]

My original plan was to make a more in-depth mockup that would go into more detail, but unfortunately I found myself much busier today than I had initially anticipated, so this is what I've been able to throw together tonight after getting home.

Hopefully it should give a better idea of what I'm describing. The thing I've learned about software is that I ultimately end up using what I like interacting with the most, even if the functionality isn't as complete as another software package. For instance, I prefer Affinity products over Adobe for multiple reasons, but the interface is a large reason. Also why I avoid GIMP. In-fact, I'm writing an open-source little utility program in Godot to make .ico files, because I dislike the process in GIMP just that much.

I'm no UX designer by any means, but I understand what I do and don't like about various UX experiences and ultimately it comes down to whether I can make it my own or if I have to fight against it. The idea with this proposal is that the user can quickly and easily adjust the UI layout to suit their needs at any given moment. Give them an easy to use, built-in tool to create new layouts visually and swap between them almost instantaneously.

I wholeheartedly believe that such an ability to morph the interface to each users' needs will put Godot's UI above and beyond all other game engines in usability and ease of access. I also believe that despite the initial work investment required to develop this layout manager/switcher, it'll ultimately simplify the code-base and introduce a number of side-benefits.

• We no longer need to worry about special cases; everything can just be a panel same as any other. This will simplify the backend UI code for the editor.
• Make all panels groupable by dragging them directly over each-other in the layout preview. Grouped panels become tabbed.
• For auto-hiding/pinning, make it a toggleable option for [any] panel. Any grouping of panels where they all auto-hide, will collapse automatically.
• If we do have concerns such as with Viewport, then we can address that to the user directly and easily with a little warning flag in the layout manager. No need for a separate popup that interrupts them.
• Add-on devs don't need to worry as much about where to attach or how to show their own UI in the editor. They can develop it as a panel the same as any other and it'll just be available in the swatch.
• Layouts can be marked as project or global layouts. That way the editor can be tailored per-project if need-be to maximize usability. You're not likely to need the same layouts developing a utility or scientific simulation as you would a game.
• For games that support modding, the editor can be provided with pre-setup layouts that are tailored to modding the game. Also useful for getting new team-members up and running quickly during development.
• Users new to Godot may need some help getting their workflows situated until they're comfortable. We can help ease the learning-curve by having the community provide access to layouts that work well for them.

If we really want to get fancy, we could also support a layout history wheel. Something that can be accessed instantly anywhere in the editor by a key-sequence or mouse-button (if the user has additional mice buttons) that shows a wheel or popup of all the most recently used layouts. Great if you're quickly swapping between two layouts, such as manual tweens (Script Editor) and animation (Animation Editor and Viewport)

[bodamat]

In my opinion, the elements should be as flexible as possible. By default, show the user how it is desirable to use and how it will be convenient for most people. But still, give the opportunity to unpin the bottom panels and move to a second monitor or attach it to the dock or tab. Yes, it may look very strange, but for some people, it will be more convenient. The top panels, which for me as tabs, allow unpinning to work on the second screen, which is very convenient.

It would be good to attach the file dock to the bottom, but also with the ability to hide to have more space to use the viewport (similar to the UE5). Also to hide the side docks to the side part of the window. For example, in the Visual Studio file manager dock, you can hide or pin. It will give much more free space for the viewport closing not necessary docks.

Also, these features can give flexibility for addons, because not everyone knows where would be better to place them. Different people like in different positions. For example, I will move the shader dock to the separated tab with an extra tiny viewport with a preview mesh sphere.

It would be good to have for example 2 inspectors to compare changes or make it easier to work on two screens when unpinning tabs on top. In the first inspector, you can lock by a special button to view information about one node and then click on another node to show data in the second inspector to compare. Аnother example is having 2 filesystem docks to move files between different open folders etc.

A great opportunity is having a menu called "Views" where all windows/docks you can open or close. Sometimes need close some docks because not needed at the moment, mostly docks from add-ons.

The big freedom to customize the workspace is the idea of ​​Godot if I'm not mistaken. Godot in different ways is the most flexible.

[EDIT]
I made some mockups for my ideas

View menu:

Move dock popup menu. Better is change than move because a dock will have another size and type. Not every functionality could work. So in some docks could be disabled for example "change to tab", but I think to stay it and users decide where is convenient for them

Hide side docks:

Highlight part of the space to move a dock. For newbies more obvious is just drag and drop docks. So would like to see when drag dock to someplace on the window, it highlights the space or expands.

[peastman]

As has already been brought up in this thread, it takes loads of clicks to open shader editor in some contexts:

Select Node in Scene
Click on the Shader Material
Click on the Shader

Now click on the viewport. Boom, shader editor is gone.

Having recently come to Godot as a new user, I found this confusing. It seems to me that shaders are inconsistent with the rest of the editing UI. A MeshInstance contains a Mesh, which contains a Material, which contains a Shader. When I click on the mesh or the material in the inspector, it expands to show the relevant UI. The parent's settings don't disappear. They just get pushed down. It also remembers the state of the inspector for each node, so when I click back to it I see the settings I was last looking at for that node.

But click on the shader and the content of the Inspector completely changes. All the other settings disappear. That's confusing for a new user. It also isn't remembered. If I click on a different node and then come back, it doesn't remember I was editing the shader. That's inconvenient.

How about making it work more like other resources? Click a shader and it expands within the existing inspector rather than completely replacing it. You wouldn't want to put the shader code in the sidebar, of course. That should still be at the bottom. But it should be linked to the inspector. Expand the shader and its code window appear. Collapse it and the code disappears. Select a different node and it disappears. Click back to that node again and the code window reappears.

[me2beats]

I like the idea to make docks and panels more flexible.
Maybe more implementation details and images would be helpful tho.

[me2beats]

Also I propose multiple bottom panels

[sosasees]

@bodamat has a good point. summary:

• new users would have a much harder time finding out that they can switch between 2D view and 3D view by selecting a 2D/3D node
• he wants an editor setting that disables the automatic switching between 2D view and 3D view when selecting a 2D/3D node

this means that merging the 2D tab and the 3D tab is bad.
this means that the new main screen tabs arrangement should be
2D / 3D / Script / Docs / AssetLib
instead of
Scene / Script / Docs / AssetLib.

[abgenullt]

I also would like to use a "bottom dock" position. I often use godot as a smaller window to compare or watch something. With the FileSystem panel at the bottom I could see the whole file names.

[Norrox]

Would it be possible to have the "run" window open in a new tab in the editor, instead of opeing a new window ?

[Calinou]

Would it be possible to have the "run" window open in a new tab in the editor, instead of opeing a new window ?

This is being tracked in #1864.

[sosasees]

@Norrox maybe, but i would still find it more useful to open the game in its own window when playtesting: this way, i can test how big the screen is for real players and how resizing the window impacts the game, without having to export the game first.

this is in my opinion an improvement when i switched from Unity to Godot.

some people like the Tab approach better — but not everyone; so if this option exists, it should be possible to revert.

but i agree that the game falling into the background when clicking inside the Godot Editor is a problem. i would find it much more useful to just ensure that the game window always displays above the editor window: the problem is fixed and the benefits of the game running in its own window are preserved.

[Calinou]

i would find it much more useful to just ensure that the game window always displays above the editor window

You can enable the Always On Top project setting with an editor feature tag override. This way, it doesn't apply to the exported project.

[ngreve]

Regarding the run window:
Currently the game/run window always opens in the middle of the screen, independent of its last position. It would be nice when it would (re)open at the same position, it was left before. This would be especially useful on a multi monitor setup.
(I don't know if this belongs to the Dock System topic)

[Calinou]

Regarding the run window: Currently the game/run window always opens in the middle of the screen, independent of its last position. It would be nice when it would (re)open at the same position, it was left before. This would be especially useful on a multi monitor setup. (I don't know if this belongs to the Dock System topic)

This should be discussed in its own proposal. Note that you can already customize the starting position of the project window in the Editor Settings (in the Window Placement section).

[ngreve]

For the people that gave a thumbs up and anyone else who is interested in the run-window suggestion/discussion:
I've opened a proposal for that #4900.

[abgenullt]

I would prefer a system like in Visual Studio or Rider, where you can simply drag panels to every side or panel. Or even out of the window to create a new one. From there, you can again dock any other panel or window..

With such a system, there is no need to think about "that layout", because it can be customize in any way..

[reduz]

I'm revisiting this proposal again because my feeling is that it's not necessary anymore, based on the following arguments:

• Since many of these issues were raised, the problems in the contextual system were mostly fixed on a case by case basis (Shader editor is now standalone, several of the bottom dock editors were moved to inspector plugins where they made more sense, script editor does not focus out when clicking nodes, etc). The real pain point seem to have been the contextual editors on subresources and now these are mostly gone.
• It seems to me that what most users really want is the ability to move the filesystem dock to the bottom to have a layout more similar to the one in Unity, while allowing to extend the bottom dock to the left. This could be implemented as an option without adding a lot more flexibility to the system.
• Others here requested that the game window should be docked. Unfortunately this is not technically as simple because, unlike Unity, Godot runs the game in a separate process. This has different advantages and disadvantages (main advantage is its far more stable, the game starts immediately and that you can continue editing your scene, have changes sent to the running game and not lose your changes). With Vulkan, it may be possible to embed the game window on the editor using shared memory but it would still not allow you to see the game running in the editor panels.
• Another very requested feature is the possibility to undock the script editor. This is, again, unrelated to this proposal and will hopefully be done at some point in the 4.x releases. The challenge of this is that, as all the application draws at once, the 3D window can really slow down the script editor so it should be somehow freezed while the text editor is focused, which is not as easy.

[OuTopos]

I would prefer a free dockable system that works on multiple monitors. It doesn't have to be interpreted to what I really want. But I'm just speaking for myself.

[reduz]

@OuTopos this for the most part already works in Godot 4, as you can already dock out the tabs to separate windows and eventually it will be possible to do this with script editor in the not so far future.

[Zireael07]

eventually it will be possible to do this with script editor in the not so far future.

Fingers crossed!

[alfredbaudisch]

@reduz and what about multiple Inspectors like in Unity, in a way that you can tweak and compare values of multiple Nodes? You can also do this with UE, basically opening each Blueprint ("GameObject") in a new Window. It's a must imo, since this situation is very very common - the need to tweak/see/compare/etc multiple nodes/gameobjects at the same time.

[seppoday]

With regard to tabs, I really found the way that the script and viewport share the same tab extremely confusing, since the tab name is always the name of the open scene, but you can change to a different script and it will still show the scene name in the tab. While I'm not sure an open tab per script would be great, I do think at least giving the script editor it's own tab that shows the current script name, and giving tabs an icon for the editor type (2d, 3d or script) would remove some of the confusion.

You might want to check that disscusion: #6499

[SlugFiller]

People have mentioned it, and danced around it, but no one gave a concrete argument about it: Why NOT use the Blender model for docked layout?

Blender makes the issue of dividing the window into docks, and deciding which dock is where, into orthogonal issues. The splitting is done by allowing to horizontally or vertically split any dock into two, drag the split line, or merge two split docks back into one. "Moving" a dock is not an option, and it doesn't need to be.

The key to this is that any dock can serve any purpose. A drop-down at the top of each dock area chooses which contents it actually has. So, for example, swapping between the FileSystem and Scene tree docks doesn't require messing with the layout at all. You just open the drop down in each of the dock areas, and pick the content that you want there.

The important key to this, of course, is that you can have, for example, the Scene tree, in two or more docking areas at the same time. Essentially, all the docks are actually the same dock, which contains all of the editors at once, separated by a drop-down instead of tabs.

Aside from the freedom, I actually find a lot of use cases for doing things this way. First, having the script editor open along with the scene would allow merging it with the shader editor. Second, when editing tool scripts, I actually prefer real-time updates from script than from shader. The latter actually burned me once because I created a loop, and before I could put in the stopping condition, Godot tried to run it, and, obviously, crashed, because the half-written shader had an infinite loop.

But it's not just shader and scripts. Having 2D and 3D open at the same time is necessary for 2.5D games. Where you move and object (physics+collision) in 2D, and a tool script copies the transform to a proxy object in 3D (graphics), and you want to see the actual drawn 3D layout and not just the collision shapes.

Incidentally, since this model makes layout and contents orthogonal, it's possible to have the latter without the prior. i.e. Have a preset number and arrangement of dockable areas, but be able to freely choose what content presented in each. e.g. Put a script window where the inspector currently is. I don't see any good reason for doing it (other than it being less work), but it's an option. And already an improvement over the current static layout.

On the topic of "What if the 3D scene is heavy, and it slows down the script editor". It's possible to detach their drawing rate by changing the 3D editor's viewport from UPDATE_ALWAY to UPDATE_ONCE, then use a timer to update it at some set intervals that ensures it doesn't take too much resources. From the get-go, a text editor doesn't exactly need 60 FPS (which the game itself does), so it doesn't seem likely that one would have a scene so heavy that you can't properly edit the script (but still have a playable game). And if it does come to that, you can always switch the 3D viewport's dock to a different view.

[jordanlis]

Hi everyone, not sure to understand what this discussion will give as a concrete result, but I just realized that I created a proposal that is kind of the same than the original message of reduz :
he bottom panel should still look different than the side docks, because you can collapse the panels to gain visibility and expand them (respect to the viewport) when you need to use them (or when a contextual editor needs to pop up). Keeping this distinction is important. This way, visually, there should be not any change in respect to what we have now.

I really think that the bottom panel should be improved in order to be "only contextual" or display by default only usefull tabs
#7300
So maybe people from this discussion could look at it and it could give a concrete result because I think the proposal is not too much vague

On the blender part, I don't see why we should follow what they do. We should make proposals based on the current panel system, which is quite good according to me.
I agree that we shouldn't redo everything just to do what blender or other softwares are doing. At least, why should maybe study what other game engine does for example rather that 3D softwares.

[darkhog]

I think everything should be turned into a dock (including console, etc.), especially since Godot now supports multi window mode. This includes being able to dock anything, anywhere, including weird layouts, such as having console/debugger on the side. It should be up to the user to setup his/her workspace the way he/she likes it, the editor should be as layout-agnostic as possible. 

Finally, different views (2d/3d/script/assetlib) should be replaced with dockable script/2d scene/3d scene/asset lib windows and the concept of different screens should either be retired or turned into something like Blender's Workspaces where user can configure them to his/her liking and have as many or as few as he/she wants to.

For example, I'd love to have a split view with script editor on the one half and the scene view on the other, but currently it is not possible.

[Gromnax]

Hi there. I'd like to put my 👍 on the original suggestion as well as giving out another use case.
I'm used (well, at least I was at a time) to coding while having the documentation under my eyes, but now, I'm forced to constantly switch between the documentation and the code, which is a bit of a shame.

I've tried to do an (ugly) mockup to better express what I mean, here it is.