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

[DriNeo]

It seems like a lot of the posts prioritize freedom so I suggest to take inspiration from text editors, or Tmux if you prefer. So the editor is made of splittable views in any reasonable number of splits. The difference is that Godot displays various editors and not only text. The split direction can be decided by the height-width ratio, keyboard shortcuts, or simply two buttons in the view top bar (I forgot these in my mockups) one to split vertically and the other for horizontal split. The layout can also be decided by scripts. As instance a default script can force the animation player to take the full width of the screen at the bottom.

I rougly drew an example of such editor. Sorry for the quality but this should give the rationale.

In the first image the dropdown list content is dependant of the opened resource. If the scene doesn't contain a script the text editor isn't available in order to limit the size of the dropdown.

[bodamat]

Looks awesome, really so much freedom, and everyone can configure how they want. Also, tabs will be the different layouts. So, in the 3d tab, you will have configured viewport, inspector, and other needed docks, but in the script tab, you will have 2 scripts dock and maybe some others like in the mockup. But in this type of layout would be good to create your tab. This all reminds me of today's Blender style. But maybe add also some limits, especially for viewports for performance issues.

In general sounds reasonable, but it had some limitations: this could be not easy to understand for new users and the UI looks complex. On another point had great ideas that different tabs need different docks layout and creating some custom tabs would also be convenient, for example, for shading.

[afk-mario]

This is exactly how Blender UI works, I like it but it does take a lot of time to get used to it and a lot of work to do right, I don't think it's what the team is looking for

[bodamat]

Sometimes is so frustrating when you select documentation and it opens a new tab in the script dock than in anything else. So in my opinion would be good to make an extra tabbed dock for documentation. It will be showing new users that Godot has offline documentation and also make it much simpler to switch between scripting space and documentation space

[sosasees]

i think the 2D and 3D tabs could be merged into a Scene tab without removing any functionality, because i never switch between 2D view and 3D view by clicking these tabs, but by selecting the 2D/3D node that i want to edit in the Scene Tree.

i also agree with @bodamat that separating the Script and Documentation tabs is good.

this means that the tab row could change from 2D / 3D / Script / Asset Library to Scene / Script / Documentation / Asset Library.

[bodamat]

@Sosasees 2D and 3D tab is good and tell that this is a completely different rendering approach. I used it and switched between it clicking nodes also. If we merge it then for someone it will be the same as Unity does, but in reality no. When I work only with 2D games or UI apps then I can hide all 3D stuff by 'Manage Editor Feature Profiles'.

[sosasees]

If we merge it then for someone it will be the same as Unity does, but in reality no. When I work only with 2D games or UI apps then I can hide all 3D stuff by 'Manage Editor Feature Profiles'.

sorry for being unclear: i didn't think of merging the 2D renderer and the 3D renderer. that Would be bad.

i thought of the same 2D view and 3D view that we have right now still being separate behind the scenes, just that we no longer see the separate 2D and 3D tabs but instead a Scene tab that gets mapped to either the 2D view or the 3D view depending on what kind of node is selected.

[bodamat]

Still, it is a lit bit confusing for newcomers how to switch between 2 views. It's not obvious to click to node and the view will change. For me, I will even remove this functionality in the settings, because it is sometimes so annoying when you want just select this node in the current view.

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