Automatically hide ImGui decorations on windows hosted in a viewport with OS decorations enabled

[allkern]

Version/Branch of Dear ImGui:

Version 1.92, Branch: docking

Back-ends:

n/a

Compiler, OS:

n/a

Full config/build information:

n/a

Details:

My Issue/Question:

When using viewports with OS decorations enabled, ImGui titlebars are still displayed below the OS titlebar, it would be pretty nice if the ImGui titlebar was hidden when the window is dragged out of the main viewport.

Attached below is a screenshot comparing viewport windows with and without ImGui decorations.

Screenshots/Video:

Minimal, Complete and Verifiable Example code:

[ocornut]

Thanks for suggesting this.
I have to admit that I was a little surprised this hasn't been requested before, AFAIK it hasn't but presumably it is because using io.ConfigViewportsNoDecoration = false as you did as as a global flag is partly broken. But this topic becomes a defacto good location to discuss this.

Naive patch would be:

        WindowSelectViewport(window);
        SetCurrentViewport(window, window->Viewport);
        SetCurrentWindow(window);
++      if (window->ViewportOwned && (window->Viewport->Flags & ImGuiViewportFlags_NoDecoration) == false)// && g.IO.ConfigViewportsPlatformDecorationDisableImGuiDecorations)
++          window->Flags |= ImGuiWindowFlags_NoTitleBar;
        flags = window->Flags;

I can see at least four issues with this:

• (1) Missing a way to add imgui resize markers (very easy to fix).
• (2) If toggling _NoTitleBar we would want to adjust window size accordingly (a little bit hairy, it could impacts settings, user constraints etc but doable).
• (3) Decorated windows tend to have (at least in Windows) minimum sizes which you cannot override. (3.1) Which itself may be a problem for some types of windows. (3.2) But mostly, it exhibit a general issue which is that we assume that OS WM applied the size/pos we requested, which is in this under Windows doesn't. The net result is that currently if you to resize too small, rendering will look broken. We should fix this assumption and it would generally improve the situation with e.g. Multi-viewports / virtual viewports #1542. Actually and interestingly this is the most easy way to reproduce this behavior under Windows which is otherwise more common on Linux or macOS.
• (4) There would currently be no way to dock that window with default settings (see Docking via the native window title bar #5074) unless using io.ConfigDockingWithShift. The reason being that while dragging from windows title bar: (4.1) in 95% applications on Windows app gets into a modal blocking loop where underlying app refreshes are not visible and (4.2) It would be difficult to wire the native moving signal for all backends, but it's something we want to explore as a general solution to Multi-viewports / virtual viewports #1542 etc. So more likely (4.3) in the meanwhile we would to add a specific "drag-dock" mini widget in a corner to do this?

If you are willing to use io.ConfigDockingWithShift = true immediately and don't mind the bug in (3.2) you could technically hack this right away, but the full path to this is going to require quite a few steps.