Input/Nav issues when docking a nested window in the same docknode as its parent

[0xSombra]

HEAD: a5ba268
Version: 1.78 WIP (17703)
Branch: docking
Back-ends: imgui_impl_dx11.cpp

A nested window docked in the same docknode as its parent "eats" input from other windows as it keeps getting/losing focus each frame.
It's more of a user error than a bug, but would it be possible to add a way to prevent nested windows from being docked in parent's docknode? (and parent's parent, etc)

ImGui::SetNextWindowPos(ImVec2(0, 0), ImGuiCond_Once);
ImGui::SetNextWindowSize(ImGui::GetIO().DisplaySize, ImGuiCond_Always);
ImGui::Begin("RootWindow", nullptr,
  ImGuiWindowFlags_NoTitleBar
  | ImGuiWindowFlags_NoBackground
  | ImGuiWindowFlags_NoMove
  | ImGuiWindowFlags_NoResize
  | ImGuiWindowFlags_NoScrollbar
  | ImGuiWindowFlags_NoScrollWithMouse
  | ImGuiWindowFlags_NoBringToFrontOnFocus
  | ImGuiWindowFlags_NoDocking);
{
  static bool DockspaceInitialized = false;
  static ImGuiID DockID_Root = ImGui::GetID("Dockspace");
  static ImGuiID DockID_Left, DockID_Right;
  if (!DockspaceInitialized)
  {
    ImGui::DockBuilderAddNode(DockID_Root, ImGuiDockNodeFlags_PassthruCentralNode);
    ImGui::DockBuilderSplitNode(DockID_Root, ImGuiDir_Left, 0.4f, &DockID_Left, &DockID_Right);
    ImGui::DockBuilderFinish(DockID_Root);
    DockspaceInitialized = true;
  }
  ImGui::DockSpace(DockID_Root);

  ImGui::SetNextWindowDockID(DockID_Right, ImGuiCond_Once);
  ImGui::ShowMetricsWindow();

  ImGui::SetNextWindowDockID(DockID_Left, ImGuiCond_Once);
  if (ImGui::Begin("window 1"))
  {
    static int x = 0;
    if (ImGui::Button("click me"))
      ++x;
    ImGui::Text("Clicked %d time(s)", x);

    ImGui::SetNextWindowSize(ImVec2(210, 50), ImGuiCond_Once);
    ImGui::Begin("dock me with window 1/2");
    ImGui::End();

  }
  ImGui::End();

  ImGui::SetNextWindowDockID(DockID_Left, ImGuiCond_Once);
  ImGui::Begin("window 2");
  ImGui::End();
}
ImGui::End();

[ocornut]

Hello,

Thanks for the report. I am going to look into it but I'm not sure it would be safe or sufficient to use "nested" relationship to apply a docking restriction. There's currently no link stored between "dock me with window 1/2" and "window 1" internally, sure based on the CurrentWindowStack[] we could infer than visibility of one is tied to the other, but I there are other cases where the same thing could happen, e.g.

bool window_1_open = ImGui::Begin("Window 1");
if (window_1_open)
{
   ImGui::Button("click me"));
   [...]
}
ImGui::End();

if (window_1_open)
{
    ImGui::Begin("dock me with window 1/2");
    ImGui::End();
}

A simple refactor on your end would make the suggested detection fail and yet you'd have the same issue happening.

I'd be more in favor of adding more mechanism to explicitely request those docking constraints (e.g. evolve the ImGuiWindowClass mechanism).

My intuition is that the current way the issue manifest itself is kind of sane, because it makes it clearer to the programmer what is happening, vs having docking be mysteriously made unavailable because one specific tab in a dock has one specific window.

I also agree and understand it is currently a little unsatisfactory and we have to come up with more solutions.

PS: Interestingly, on restart your code has a different issue, as calling DockBuilderAddNode() with an already existing node is currently undefined. The node already exist and was already split, so you end up trying to split the parent node twice. Adding a simple DockBuilderRemoveNode() before AddNode() will work. I'll have to think if we can make AddNode automatically remove existing node, probably a good thing to do.