Per-Morten
commented
1 year ago Thirdly, (not very important) This approach doesn't feel super "intended" but more "workaroundy". Using state storage to store "single frame behaviour" isn't something I normally need to do in ImGui. Now every begin/end need to have this "little dance" of using state storage that's modified inside the window. Note, so far I've been able to make all my tools with a minimal amount of abstractions/utilities on top of Dear ImGui, so this feeling might just be lack of more complex experience.
So I at least figured out that I can avoid using state storage by using begin/end to get into the context of the window https://github.com/ocornut/imgui/wiki/Tips. Only really solves the third issue (easier to abstract away in a function). But, is this allowed, am I allowed to set the window dock id after I've already created the window once?
{
ImGui::SetNextWindowClass(&window_class);
char window_a_heading[256];
std::sprintf(window_a_heading, "Item A##%d", dockspace_id);
// Create window just to check if we must be reparented.
bool must_be_parented = false;
if (ImGui::Begin(window_a_heading))
must_be_parented = ImGui::GetWindowDockID() == 0 && !ImGui::IsKeyDown(ImGuiKey_LeftShift);
ImGui::End();
if (must_be_parented)
ImGui::SetNextWindowDockID(dockspace_id);
if (ImGui::Begin(window_a_heading))
{
// ...
}
ImGui::End();
}
ocornut
Version/Branch of Dear ImGui: Version: 1.90.0 Branch: docking
Back-end/Renderer/Compiler/OS Back-ends: imgui_impl_win32 + imgui_impl_dx11 Operating System: Windows 11 x64
My Issue/Question: I'm creating a "file inspector" debug tool, where each root window (Root A and Root B in the gifs) is a "file". Each of these files can have multiple items (Item A->Item D in the gifs) which is an object within said file. I want to be able to split/layout all the different objects within a file, but I never want those those objects to be docked to anything other than their original windows (to avoid confusion as to what file an object belongs to).
Basically, to summarize the functionality I want (see gif): I want Item A and Item B (and any other items I would add to Root A) to be able to be split into all endless combinations that docking allow, but they must always be docked somewhere in their original dockspace in the Root A window.
I'm wondering what's the best way to achieve this functionality?
My current approach (see code snippet) is to only allow layout changes (undocking) when the user is holding the shift key. If the user lets go of the shift key and the window is not docked to its original dock space I force it back there. I'm using StateStorage to track whether or not the window needs to be docked in its original dock space.
This approach works, but has some issues: Firstly, it doesn't work if ImGuiWindowClass::DockingAlwaysTabBar is set to true. Because then the item windows creates their own docking space when they are undocked from the root windows.
Secondly, If you have an undocked root, are in the process of moving an item window and let go of shift, the root is moved to where your mouse cursor is (see second gif showing the difference in behaviour).
Thirdly, (not very important) This approach doesn't feel super "intended" but more "workaroundy". Using state storage to store "single frame behaviour" isn't something I normally need to do in ImGui. Now every begin/end need to have this "little dance" of using state storage that's modified inside the window. Note, so far I've been able to make all my tools with a minimal amount of abstractions/utilities on top of Dear ImGui, so this feeling might just be lack of more complex experience.
To somewhat repeat my question: Is there any better way to achieve the functionality that I want?
Screenshots/Video Gif 1: Showing current & desired behaviour
Gif 2: Showing the broken move behaviour
Standalone, minimal, complete and verifiable example: