**Note**: *I opened this proposal for everybody to bikeshed on it as much as the…y 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