SlugFiller
commented
1 year ago 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
darkhog
Gromnax
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:
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:
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:
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:
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