Add support for multiple displays/screens/monitors in Godot editor

[Feniks-Gaming]

Describe the project you are working on:

I am working on a simple platformer game Mario clone right now just to learn how to use the engine.

Describe how this feature / enhancement will help your project:

My set up has 2 monitors with possibility of expanding in to 3 in a future. I would like the ability for Godot editor to have multiple un-dockable windows I can move around on my set up. Ideally I would be able to save configuration as a preset. This would make task of switching between room editor and code editor significantly easier. I could also have my inspector open in another screen without taking my monitor real estate.

Generally it would help me to have more things visible without needing to keep switching between them. I could have player scene open on right screen and level scene open on 2nd scene. I could have parent object open in one and child in other so I can better see all the available functions etc. Possibility with this are endless.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

I would see it working like here with Game Maker workspaces

Describe implementation detail for your proposal (in code), if possible:

I have not enough coding experience to give technical knowledge on how to accomplish what I request but I expect this would require significant rework to editor code itself.

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

This is enhancement that I would use 100% of a time while working on any project as it would help me to utilise more of a real estate I have in my current set up that is now just wasted space.

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

It is something that majority of users would find useful it is a feature requested since Godot 2.1 days and if not in use would not interfere with single monitor workflow for others.

Bugsquad edit (keywords for easier searching): window, pop out, popout, pop up, popup, multi-window, multiwindow, multi-screen, multiscreen, multi-display, multidisplay, multi-monitor, multimonitor

[reduz]

Hoping to be able to implement this for 4.0. The Vulkan back-end already supports multiple windows on the API side, but it needs to be implemented on every bakck-end. It will be quite a challenge, though.

[Feniks-Gaming]

I can imagine it's going to be a lot of work. 4.0 would be great timing and would definitely improve usability of the engine for many people. It was a thing I missed the most when I switched from game Maker 2

[xsellier]

I like the idea. However I would like to be able to popup the editor window from the main editor.
I want to be able to see the scene and to edit its script at the same time but from different windows.

[Zylann]

I've occasionally thought about consequences of multi-windowing like this.
I wrote a list of situations, which progressively influence the next ones as you read it so don't take all items as granted.
Although the following list isn't aiming at something like GameMaker workspace, it its more based on the way Godot works today, and how it could be expanded to multiple windows without too much work:

• Main screens should be able to undock, like the script editor which is requested very often. This include main screens added by plugins. This should hopefully be seamless because they remain "containers", whatever is inside, behaving more like tabs than fixed buttons.
• To be clear, there would still be a single instance of each editor, just located within a user-defined window. If we want multi-editors like two script editors open at once, that's a whole different beast and IMO shouldn't be added to that rework (or would be something to be dealt per-editor-plugin, or done as a complete rewrite of the editor, maybe Godot 5.0 or 42.0).
• 2D and 3D scene views being considered "main screens", if we assume them to be separately undockable, it would allow to make them both visible, which has quite a significant effect:
  • When a node is selected, there is no need to switch them since they are both visible
  • Since those screens show the scene, it forces us to duplicate the scene tabs, which could be confusing.
  • Should 2D and 3D remain actual "main screen containers"? Could they actually be a "mode" of a single usage-unified "scene view"?
  • Still due to the scene tabs duplication, would that spark the idea of having more than one scene selected? At this point it's probably easier to remain with a single selected scene, and consider 2D and 3D are not undockable, so plugins should be able to decide if their main screen can.
• Should scene tabs be duplicated? Should they remain on the "main window", leaving all secondary windows without scene tabs?
• Should the left and right menu bars be only present on the main window and not present on secondary windows? Likely, they should remain on the main window with the scene tabs, so editor plugins can decide what secondary windows contain (depends wether or not the window is standalone or managed by a dock system, see later below).
• It would be nice to be able to undock the shader editor as well, which is however not a main screen.
• Docks should be... undockable.
• Popups like Quick Find, Find in files, Project Settings or messages would have to open on the focused window, even if the editor they relate to isn't in that window. For example: windows opening with a global shortcut. Moreover, they could even open as separate windows themselves, and be free from the limitation of being constrained within the viewport.
• Modal popups like export, baking or scene loading need to lock ALL the windows, or change in such a way they don't have to lockup the whole editor.
• Closing a window should move the editors inside it back to their default location, or be closed if they have such functionality.
• Pretty obvious, but there should be a "main" window which will hide all the others if minimized, and close Godot if closed. It may also be important to decide whether a window has a place in the taskbar or not.
• The need for contextual shortcuts might become more apparent
• From what I gathered above, it seems editor plugins would have to simply decide themselves wether or not their editors can be undocked as separate windows, which they would be able to manage themselves.
• At the same time, being able to dock two editors together within a separate window could be interesting. This hints an improvement of the "dock system" to make it aware of multi-windowing that editors like Unity, Visual Studio or Blender have. I've seen two main approaches so far:
  • The main screen+docks approach, which is what Godot or Visual Studio is doing so far, and I think it's a pretty good one but I've rarely seen it with multiple screens, where usually one of the windows is the main one and others are just combination of docks
  • The everything-is-docks approach, which is what Blender and Unity are doing. This is the most generic and flexible approach but it can be messed up if you aren't well organized (note I'm not referring to usability, Blender is awful with his hidden drag handles and Unity is more intuitive but the idea remains the same).
• On the technical side, the renderer should not need to redraw all windows just because one changed. That would also mean all windows could have an update spinner (if managed by a dock system).
• The list may go on :D

With these things taken into account, the concept screenshot becomes more like this:

Since doing this can be quite a lot of work, splitting it in phases could help transitionning to this:

• First, have ability to manage multiple windows, at all. A solid API needs to be defined before we can affect the editor with it. Create windows, set their types, how they behave with the OS, assign them a viewport. That would be for 4.0.
• Second, use that API, and have ability to undock single editors (like the script editor). That could be done for 4.1.
• Later expand on other methods to organize such editors on screens with a more generic manager. Have a dock system such that popped out windows have common editor controls rather than being single editors each.
• Eventually completely rewrite the editor in version 42.0 with a new design to take better advantage of the new core features since the way Godot works today inherited a lot from the days it was more limited

[alexfreyre]

I think it is a feature that we all need but something that should be improved is the UI depending on the workspace we are using. For example, if a window has the text editor, it is not necessary to observe other buttons depending on another type of work or windows within that workspace.

[alwaysusa]

+1 here for the multiple monitor support.

Just started using Godot and love the engine so far - but the lack of multiple monitor support (through whatever method) is a little frustrating. I'm constantly resizing windows to find stuff in the current layout. Personally, I'm a fan of floating windows.

[Sslaxx]

With multi-window support now enabled for 4.0, does this make this proposal as-is redunant?

[akien-mga]

Partially fixed by godotengine/godot#37317.

[Anutrix]

Has someone already mentioned multiple 2D/3D view in this proposal? So that we can see different parts of the game at the same time? A bit similar to blender's multiview.

Or even complete replication so that we can work on different scenes same time i.e, similar to running 2 instances of Godot editor with different scenes open. Seems like OP mentions this.

[Zylann]

@Anutrix

I don't think those individual viewports were considered to become single windows though

[afonsolage]

I hope we can do this on 4.0, because I tried to use VSCode as an external editor to have the editor on another monitor, but the issue #10946 prevented me from using it.

[SoyoTamo]

for linux this would work better implementing it together with wayland, see #990 (comment).

[Calinou]

for linux this would work better implementing it together with wayland, see #990 (comment).

Supporting Wayland is irrelevant to this proposal. This proposal can be implemented independently of Wayland support.

[SoyoTamo]

Of course, i mean just a little better

[pfspace]

I love Godot's text editor. I tried to work with Geany instead to be able to code on another screen, but I always keep coming back to Godot's internal text editor. It's really awesome.

As a workaround to this issue (not being able to "modulate" the engine over multiple screens), would it to be possible to create a command line switch to disable all the default features but the text-editor?
Something like: ./Godot_v3.4.4-stable_x11.64 --text-editor

This way we could use another instance of Godot as an external text editor on another screen.

Thank you in advance.

[Calinou]

As a workaround to this issue (not being able to "modulate" the engine over multiple screens), would it to be possible to create a command line switch to disable all the default features but the text-editor?

Unfortunately, this is easier said than done for two reasons:

• Godot is not designed to have multiple instances of the editor open on the same project at the same time. You'll get conflicts on the project.godot file whenever you alt-tab across instances. Preventing text editor instances from writing to project.godot would be problematic, as writing a class_name declaration in a script requires project.godot to be updated for the class_name to work.
• Some functionality in the script editor relies on other editor panels/docks being visible, so merely hiding them is not enough (even if they're still initialized).

[pfspace]

Couldn't that be solved adding the .--sc-- file (can't figure out how to underscore here) inside Godot's folder?
I have different copies of Godot to handle different projects, each one in it's own folder.
All of them have the .--sc-- file inside.

When I open the same project on multiple instances at the same time, I can indeed edit and save files. When switch back to the original instance it displays a confirmation dialog: "The file whatever.name is newer on disk. What action should be taken?" Among the edited files is, as you said, project.godot.

Just a small annoyance but kinda works. That's why I thought it could be used exclusively as an external text editor.

Thank you.

[Calinou]

Couldn't that be solved adding the .--sc-- file (can't figure out how to underscore here) inside Godot's folder?

The ._sc_ file is only about editor settings, not project settings.

[azur-wolve]

@Zylann good points

Something that I found missing in almost any Engine is the ability, to instead of passing through an established Editor pipeline, allow you to build/customize your own.

So let all workspaces | editors | views | dockers | panels be detachable-attachable, allowing for craft interesting layouts using building blocks, where you can have all the stuff where you want it, either in separated windows, virtual desktops or displays.

It can be done by modifying open source editors and by building your own with libraries (a good example is the Rust echo-system). But when its about to an "out-of-the-box" way where it uses a well tested workflow with a good UX, not aware that such thing can be found.

Being able to customize all yourself without worrying about breaking the editor and bridge well with the underlying engine sounds like a dream setup for me. Including plugins (here the barrier between plugin and not could be diffuse).
Such thing if well done could be also enable non-expert users to operate with.

When forcing a specific workflow or layout, a lot of flexibility gets lost, and the most of the problems of fitting, coupling and compatibility raise.

[SirQuartz]

So I've known that this has been a highly requested feature for years in Godot, but until Godot 4 it hasn't really been possible, so I decided to take a stab at it now just to see what I could do. I think I've gotten pretty close with this.

Here's an early prototype I'm working on:

Floating.Script.Window.mp4

This isn't perfect, and it's just a proof of concept at the moment. Still has some bugs, but works quite well nonetheless. I don't think anything like this would even be possible in Godot 3 though, only Godot 4.

Written in native C++ source code.

[Anutrix]

@SirQuartz Looks good. You can create an MR for it. People will pitch in to help.

[erayzesen]

I agree with this proposal and I want to share some ideas on this.

I think there are some basic UI-UX design problems on the top-center bar.(2d,3d,Script, Assetlib...extension features) The top bar must be a embedded window task bar. For example If I want to use script windows as a seperate window, I should be able to break it out of the top panel. The same scenario must also apply to the items in the other top panel.(2d,3d,Assetlib...etc) I should be able to use it as a separate window and even close it if I want.

If I want to reopen the windows I have closed, there must be a "Windows" section to the top context menus (Scene, Project, Debug ... section) . When we click on the "Windows" menu, these usual windows can be reopened and used.(or close) This scenario is also intuitive for the end user.

If I close all windows what will be happen?
Nothing. There will be empty area on the center area. You didn't open any main editör window this time. Maybe you will add a info message to the empty center area. (Just like "you can open a window from the windows context menu")

Is it a problem for new users?
A locking feature is active in default settings. If the user wants to use this way, they can remove the lock from the settings.

I hope these ideas will help this proposal.

[Zylann]

Just FYI, I implemented popout in one of my plugins: Zylann/godot_voxel#414 (comment), it's working for standalone windows.

[pfspace]

Just FYI, I implemented popout in one of my plugins: Zylann/godot_voxel#414 (comment), it's working for standalone windows.

Awesome!

[jordanlis]

So I've known that this has been a highly requested feature for years in Godot, but until Godot 4 it hasn't really been possible, so I decided to take a stab at it now just to see what I could do. I think I've gotten pretty close with this.

Here's an early prototype I'm working on:
Floating.Script.Window.mp4

This isn't perfect, and it's just a proof of concept at the moment. Still has some bugs, but works quite well nonetheless. I don't think anything like this would even be possible in Godot 3 though, only Godot 4.

Written in native C++ source code.

This is amazing, can we already use it in a plugin or something ? Is it only for 4.0 ?

[aaronfranke]

This was implemented for the script and shader editors by godotengine/godot#62378

EDIT: Changed milestone for 4.x for tracking support for multiple displays for other parts of the editor, but note that the most important part, the script and shader editors, are supported in multiple windows as of Godot 4.1.

[MikeFP]

This was implemented for the script and shader editors by godotengine/godot#62378

That's awesome! It's working great!

There are still some UI/UX issues to be addressed, like other comments here suggested, but it's a great start.

One of them is that when I hit save, the focus shifts to the main window, and then quickly shifts back to the floating script editor. It should be a non-issue, but it's weird when I try to put both windows in different "Desktops" (using Windows OS). For instance, I'm editing the script in a floating window on Desktop 2. If I hit save, or run, or any other regular shortcut, the shift of focus takes me back to Desktop 1, and then gets back to Desktop 2 again, with a quick animation made by the OS, which is really jarring.

However, it's a pretty large step already, I just added this comment to document the issue. Thanks for the work!