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

DockBuilder is overriden by imgui.ini for a new window #7949

Open
TheMadDodger opened this issue Sep 3, 2024 · 4 comments
Open

DockBuilder is overriden by imgui.ini for a new window #7949

TheMadDodger opened this issue Sep 3, 2024 · 4 comments
Labels
docking settings .ini persistance

Comments

@TheMadDodger
Copy link

Version/Branch of Dear ImGui:

Version 1.91, Branch: docking

Back-ends:

Magnum

Compiler, OS:

Windows 10 + MSVC 2022

Full config/build information:

No response

Details:

My Issue:

When you use the dockbuilder to dock a window, the window is undocked after the imgui.ini file gets loaded if the ini file does not contain any settings for the window yet.

Example
Assume 2 windows:

  • MyWindow
  • MyOtherWindow

The dockspace is split in 2, a left and a right. We use the dockbuilder to dock MyWindow to the left, and MyOtherWindow to the right.

If we now run the application and make sure the new ini file is written, we would get settings for both these windows, and they are docked correctly.

If you now add a new window, MyNewWindow for example, and also dock it to the right, if you now run the application the window will be undocked if we reuse the same ini file.

If you delete the ini file the window is docked correctly at the next run.

Expected behavior
The new window should be docked if there are no settings available for it yet, as the dockbuilder sets it up, loading the ini file should not override it unless it has docking settings available for the window.

Why we need this
We are releasing a new update for our application soon that includes a new window, if the user uses a project of an older version of the app, the window will appear as a small undocked box that is hard to spot. We want it docked by default for these users as well.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

Make sure to remove a window settings block in your imgui.ini after you've saved and the relaunch the program to reproduce the bug.

// Inside an ImGui frame
static bool resetLayout = true;
const ImGuiID dockSpaceId = ImGui::GetID("root");
if(resetLayout) {
    ImGui::DockBuilderRemoveNode(dockSpaceId);
    ImGui::DockBuilderAddNode(dockSpaceId, 0);
    ImGui::DockBuilderSetNodeSize(dockSpaceId, ImGui::GetIO().DisplaySize);

    ImGuiID left, right;
    ImGui::DockBuilderSplitNode(dockSpaceId, ImGuiDir_Left, 0.50f, &left, &right);

    ImGui::DockBuilderDockWindow("MyWindow", left);
    ImGui::DockBuilderDockWindow("MyOtherWindow", right);
    ImGui::DockBuilderDockWindow("MyNewWindow", right);
    ImGui::DockBuilderFinish(dockSpaceId);

    resetLayout = false;
}

bool active = true;
ImGui::SetNextWindowPos({0.0f, 0.0f});
ImGui::SetNextWindowSize(ImGui::GetIO().DisplaySize);

ImGuiWindowFlags mainWindowFlags =
    ImGuiWindowFlags_NoMove|
    ImGuiWindowFlags_NoCollapse|
    ImGuiWindowFlags_NoResize|
    ImGuiWindowFlags_NoTitleBar|
    ImGuiWindowFlags_NoScrollbar|
    ImGuiWindowFlags_NoBringToFrontOnFocus|
    ImGuiWindowFlags_NoNavFocus|ImGuiWindowFlags_NoBackground;

ImGui::Begin("MainWindow", &active, mainWindowFlags);
ImGui::DockSpace(dockSpaceId, ImVec2(0, ImGui::GetContentRegionAvail().y), ImGuiDockNodeFlags_PassthruCentralNode);
ImGui::End();

// Window docked normally
static bool myWindowOpen = true;
ImGui::Begin("MyWindow", &myWindowOpen, ImGuiWindowFlags_NoCollapse);
// Draw window...
ImGui::End();

// Window docked normally
static bool myOtherWindowOpen = true;
ImGui::Begin("MyOtherWindow", &myOtherWindowOpen, ImGuiWindowFlags_NoCollapse);
// Draw window...
ImGui::End();

// Window not docked because settings are missing
static bool myNewWindowOpen = true;
ImGui::Begin("MyNewWindow", &myNewWindowOpen, ImGuiWindowFlags_NoCollapse);
// Draw window...
ImGui::End();
@TheMadDodger TheMadDodger changed the title Dock Dockbuilder is overriden by imgui.ini for a new window Sep 3, 2024
@ocornut ocornut added docking settings .ini persistance labels Sep 3, 2024
@cfillion
Copy link
Contributor

cfillion commented Sep 3, 2024

Forgive me if this is a genuine answer, but you commented as fast as I posted the issue, your link leads to a zip file on discord that is a supposed "fix" that needs to be installed? That just sounds very fishy.

It's malware. GitHub banned the account just now. (Please consider editing out that link in your message. 😉 )

@TheMadDodger
Copy link
Author

TheMadDodger commented Sep 3, 2024

Forgive me if this is a genuine answer, but you commented as fast as I posted the issue, your link leads to a zip file on discord that is a supposed "fix" that needs to be installed? That just sounds very fishy.

It's malware. GitHub banned the account just now. (Please consider editing out that link in your message. 😉 )

Thanks for the heads up!

@Squareys
Copy link

Squareys commented Sep 4, 2024

Possibly relevant: This is for Wonderland Editor. We set io.IniFilename = nullptr; and load it manually using ImGui::LoadIniSettingsFromDisk(path); to load/save per-project ini files.

@ocornut ocornut changed the title Dockbuilder is overriden by imgui.ini for a new window DockBuilder is overriden by imgui.ini for a new window Sep 6, 2024
@ocornut
Copy link
Owner

ocornut commented Sep 6, 2024

Expected behavior
The new window should be docked if there are no settings available for it yet, as the dockbuilder sets it up, loading the ini file should not override it unless it has docking settings available for the window.

I haven't been able to dig into this yet, but intuitively it seems like it is correct that when loading a .ini file it would write to the state of every window.

The problem is that the ID of right in ImGui::DockBuilderDockWindow("MyNewWindow", right);

Doesn't necessarily exists in the .ini file anymore. User may have shuffled things.

Let's come from it from other angle:
Possibly your "reset layout" block could be reworked (and maybe the current DockBuilder doesn't make it trivial and we can improve it) to set the docking target of "MyNewWindow" IF it is known to have no setting?

if (FindWindowSettingsByID(ImHashStr("MyNewWindow")) == NULL)
   DockBuilderDockWindow("MyNewWindow", node_id);

(potentially this could be simplified if DockBuilderDockWindow() had a ImGuiCond flag).

But this immediately leads us to a similar issue (which the crux of the complexity of the docking system, which most people haven't quite intuited): at this point choosing the "node_id" is going to be difficult, since you are coming potentially with a very different state than what was saved in the .ini file.

Do you understand the problem?

The intuitive desirable target would be to locate the "MyOtherWindow" window and dock "MyNewWindow" at the same location of "MyOtherWindow". Even if "MyOtherWindow" isn't visible anymore, it probably has a docking state.

A tangent to this issue is a new window normally shouldn't "will appear as a small undocked box that is hard to spot.". Normally it doesn't but I am not path what this path leads to.

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

No branches or pull requests

5 participants
@Squareys @cfillion @ocornut @TheMadDodger and others