*EDIT*

**Please prefer creating new issues (and referring to this one with a #1542 marker) when reporting bugs or asking questions. This thread is currently too big to be useful.

October 2020: Wiki page: https://github.com/ocornut/imgui/wiki/Multi-Viewports

IF YOU SUBMIT/DISCUSS AN ISSUE RELATED TO MULTI_VIEWPORTS:

• Always state which imgui_impl_xxx platform and renderer back-end files you are using.
• If you are using imgui_impl_glfw.cpp, state which version of GLFW you are using. If you are using imgui_impl_sdl2.cpp, state which version of SDL2 you are using, etc.
• Always state your OS type, OS version, window manager and extensions (in the case of Unix systems).
• If the issue happens in your own application, always also tests in the examples/ application and state if you have the same problem with those applications.
• Make sure to check how the main.cpp of the examples/ application is currently setup for the viewport branch.
• Never state "there is a crash/assert" without providing an associated callstack and details.

January 2019: Viewport and Docking branches have been merged to simplify maintainance. Use the 'docking' branch to test multi-viewports.

December 2019: See Glossary: https://github.com/ocornut/imgui/wiki/Glossary#multi-viewports-terms

January 2020: If you want to implement multi-viewports in your custom engine, the easiest path is to read the comment around ImGuiPlatformIO along with the bottom sections of e.g. imgui_impl_glfw+imgui_impl_opengl3 to learn from it.

For Linux/Mac specific issues please post in #2117.

Creating this thread to discuss and tag commits related to an upcoming feature.

It somehow relates to Docking (#2109) in the sense that current work on docking created growing expectations to get this working. But it's also mostly separate code, and for various reasons I think this will probably go in master before Docking. It will need testing and feedback.

If you follow the Docking thread you may have seen this already: [...]
And more recently I improved transition and it's somewhat magical:

What happens here essentially if that the code creates borderless (undecorated) windows with a dedicated DirectX/OpenGL context on the fly, create imgui viewport to cover this os window, and move the window there..

Basically it consist in two parts:

• dear imgui will support a new concept called "viewport". A single imgui context can drive multiple virtualized regions, as shown in those GIF. Using a single context makes sharing state natural (things like settings, tree nodes state or cross windows drag and drop). There are still various problems to solve related to persistence, mouse position, etc. but overall it's not a crazily complex feature.

• To support this feature the backend code (imgui_impl_xxxx files) needs to be reworked obviously. It puts additional complexity on that code and not all engine will support it. That part needs to be both optional and as out of the way possible. I suspect we will need to iterate on that a lot, both to get the functionalities right, and because I worry a lot about the imgui first-time user experience and impression, and the additional complexity is very undesirable there.
  I suspect I may end up re-factoring a lot of the examples/ code.

If you are interested I will be looking for feedback and early adopters, hopefully starting in January some of this can be in a branch.