Allow opening and closing any editor dock

[kitbdev]

Describe the project you are working on

Godot Editor

Describe the problem or limitation you are having in your project

The Docking system in the editor has limitations for managing docks.

Having docks that you don't use just adds clutter to the screen.
There is no easy way to see a list of all docks or find a specific one, and they can be hidden in clipped TabContainers or in a floating dock somewhere.

Lots of plugins with docks can cause clutter and you may not want to disable the entire plugin.
A plugin can open and close dock but then it has to manage opening and closing by itself.
Hiding docks in the TabContainer of another dock is possible, but gets annoying when you want to find one or move them somewhere else.
Some docks are not needed all the time and not contextual enough to be hidden. - Such as the History dock, Import dock, Audio panel, and docks from plugins. These are useful, but they don't need to be available on the screen at all times if the user doesn't want them. (I'm not saying these should be closed by default, but closing should be an option.)

Floating docks could also be lost off on another monitor and hard to find.

There are other proposals that mention opening and closing docks, but none are focused about them. I wanted to get feedback on this specific feature by itself.
Also this proposal is not about the main view or bottom bar, just regular side docks.

mentioned in:

• Improve the editor docking system for better usability #1267
• Editor overhaul mockup - ways to add full customizability #7233
• Improved Dock System #4565 (comment)

prerequisite for:

• Add support for opening multiple Inspectors (or improve workflow when editing multiple nodes/resources properties at the same time) #7459

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

Allow any Editor Dock to be closed and opened.

Add an option to each dock tab to close it.
It should show in a context menu and maybe an X on the tab itself.
This hides the dock from the screen and maybe stops processing it at all.

Add Window menu in the Title bar.
Shows a list of all available docks.
Clicking on one will open the dock (if not already open), make sure it is visible, and focus on it.
Plugins can add a dock to this list without opening the dock, allowing for optional UIs that can be easily used only when needed.
Window is a standard across many applications, so the use will be clear to users.

Contextual actions still work on docks even if they were closed.
Example: clicking on a 'Show in FileSystem' menu item will open up the FileSystem dock if it was closed.

Benefits

• Easier managing of docks
• Less clutter on the screen
• Easier to find a dock you want to use
• More focused workflows can be created with a layout
• More docks that have a very specific purpose can be created
• Plugins with many docks are easier to use

This is different than Editor Features which completely disables part of the editor.

• This is only for docks and applies for all docks
• docks can be reopened easily and quickly
• docks aren't fully removed

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

The EditorNode will maintain a list of all docks, with their name, location, shown status, Control, etc.
This is already done for floating docks only, this can be unified together.
Each dock should have a unique name (they already need to, but only for loading layouts).
The default names should be good enough for this, but we may want to prefix them with
'godot_' or something to avoid collisions with plugins, and recommend they do the same.

Add Window menu in the EditorTitleBar MenuBar.
The menu will need a unique string to represent the dock (probably).
We may want to add support for folders and grouping, for this we could have the menu item name be treated as a path. For example 'My Plugins/Test Plugin'. Every dock with the same folder prefix is in the same folder, everything after is the name shown in the menu item.
The menu could possibly show other dock related functionality - save and load layouts, force recenter a dock, ...
Optionally this menu could use checkboxes for each dock to make it easier to close docks as well.

If adding an 'X' directly on the tab of a dock is too easy to accidentally close and lose a dock, we can just put it only in the context menu.
Closing could be as simple as setting the tab visibility in TabContainer, but it might be a better design to remove it and put it somewhere else (or keep it out of the tree to prevent processing maybe?).

Plugin API
The current API has some dock functionality in EditorInterface and some in EditorPlugin.
If my understanding of EditorInterface is correct then they should probably all be in there.
We could better organize it though by making a dedicated EditorDockManger to manage all dock related functionality.

We can add a close_dock(StringName dock) and open_dock(StringName dock,DockSlot slot) if a plugin wants to open or close automatically, but preferably the user is the one in control of opening and closing docks.

Plugins will need to tell Godot if they have a dock they want to not open by default.
We can use a method add_control_to_dock_list or something. add_control_to_dock and other functionality effectively stays the same, but also adds the dock to the Window menu.
Alternatively, we could make the dock creation experience easier by providing an annotation or a class to inherit (or interface to implement) that automatically adds it as a dock in the list, since we don't need a default destination anymore.

Plugins may also want a opened/closed signal, but the existing visibility notification may also be enough.

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

Not really, it needs to interact with all editor docks and plugins that add docks.

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

Core part of Editor UX and dock management.