Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docking: Window constraints are not respected after undocking via tab bar #4228

Open
AidanSun05 opened this issue Jun 14, 2021 · 1 comment

Comments

@AidanSun05
Copy link

AidanSun05 commented Jun 14, 2021

Version/Branch of Dear ImGui:

Version: 1.84 WIP
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp
Compiler: Visual Studio 2019 version 16.10.1
Operating System: Windows 10

My Issue/Question:

I'm developing an application where many windows (5-10+) could potentially be open at a time, so I'm using the docking branch to provide a convenient way to organize and group them together. I'm also using ImGui::SetNextWindowSizeConstraints({ minWidth, minHeight }, { FLT_MAX, FLT_MAX }); to set a minimum possible size for each window. This is to prevent them from resizing so small that their contents get clipped or squished together.

When a window is docked, I've noticed that its constraints are not respected; the user may resize the window past its minimum size. From past issue threads, this IS expected behavior. However, a window only regains its constraints when it is undocked by dragging its tab, not its tab bar.

What I mean when I say "tab" and "tab bar" on a docked window

image

Screenshots/Video

This is a demonstration of the issue. Please see the section below for important notes:
Animation
(Click for full size)

Standalone, minimal, complete and verifiable example:
This can be reproduced in the demo application. However, this only works with a Dockspace, where both the tab and the tab bar can be dragged to undock a window. If a window is docked to another window, dragging the tab bar moves both windows so the only way to undock a window in this configuration is to drag its tab, which always has no unexpected behavior.

  1. Clear the Dear ImGui persistent storage by deleting imgui.ini if it exists.
  2. Start the demo application. (Compile it if needed.)
  3. Activate the Dockspace example and the Constrained Resizing Window (I'll call it the CRW).
  4. Make sure that the constraint setting in the CRW is "Resize Vertical Only".
  5. Try resizing the CRW with the bottom-right handle. Notice how you can't change its width because of the constraint.
  6. Dock the CRW into one of the slots on the Dockspace.
  7. Undock the CRW by dragging its tab until it is free.
  8. Try resizing the CRW again. It should still have its width locked.
  9. Dock the CRW back into the Dockspace.
  10. Undock the CRW, this time by dragging its tab bar.
  11. Resize the CRW with the bottom-right handle. It should be able to resize in both dimensions because it hasn't regained its constraints after being undocked.

I'm assuming this is because undocking from the tab and tab bar are handled differently, with one re-applying the constraints and one not doing so.

@ocornut
Copy link
Owner

ocornut commented Jun 15, 2021

Thank you @AidanSun05, everything you said is correct.

Dragging a window from its tabs undock the window from its node, making it a standalone window
Dragging from the tab bar moves the whole dock node.

In theory, we would like that a dock node with a single window should at least behave exactly the same as a standalone window (should be minimal code difference). In the current architecture there are unfortunately many differences and "regressions" in that case.
This comment has a list: #2386 (comment)

Effectively there has been a lot of smell in that docking code and it's been my plan to rewrite it from scratch as docking v3 (docking v2 is the one that's available, docking v1 was never released). In the past few months we put more energy at writing tests to fix a few issues of v2 and mostly to simplify the transition to a new version, but I don't have visibility of when that'll be possible. In fact, a good portion of current open Docking issues will probably be on hold until we rewrite docking. But simultaneously those issues are important as they constitute a checklist to compare us against.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants