More general ini file support?

[jarikomppa]

The ini file support appears to only store pos, size and collapsed values for the windows. It would be convenient to be able to use the ini files to store other settings as well.

In my case I was looking to add the information on whether the window should be open or not, but the interface could be even more general (some kind of registry).

[ocornut]

Yes I suppose it would be desirable, I was considering it could be a separate library (not sure if that's right or not). If you want to develop the idea and draft an API or how it would work, I haven't really thought about it yet. I believe it would have huge ramification.

Note that it could also be applied to ImGui own storage for e.g. whether a tree node is opened or not. though the current design for those is that we have a set of hash->value and it's not really designed to persist, so dumping out the hash->value map would work but that would be anonymous and impossible to "clean". So better off with a more high-level design involving setting a state of whether tree state are saved, e.g. PushTreeStatePersistent(true); and the tree calls may use the persistence API providing more info that just hashes.

[thennequin]

Try this https://gist.github.com/thennequin/c604c8caa38048a1fcdc

[r-lyeh-archived]

Maybe it would be just enough to have an api modelled after the events, exactly like hovered or active items are used? In that case, every widget would have to load/save their own variables, as opposed to have an automated solution.

// pseudocode
ImGui::Begin("color picker");

    static float color[4];
    ColorPicker4(color);

    if (ImGui::IsItemHovered()) {
        ImGui::BeginTooltip();
        ImGui::Text("I am a tooltip");
        ImGui::EndTooltip();
    }

    if (ImGui::IsItemLoading()) {
        ImGui::Load("main.window4.color", color);
    }

    if (ImGui::IsItemSaving()) {
        ImGui::Save("main.window4.color", color);
    }

ImGui::End();    

[r-lyeh-archived]

If you want to get rid of the manual tagging and provide some smart nesting support, then add push/pop states

    if (ImGui::IsItemLoading()) {
        ImGui::BeginLoad("color"); // supposedly inside main -> window4 context already
        ImGui::Load(color);
        ImGui::EndLoad();
    }

[codecat]

Any update on this? I think you wouldn't even need a separate Load/Save function, you could just do something like this:

ImGui::BeginConfig("SomeSection");
ImGui::Config("SomeKey", &SomeBool);
ImGui::EndConfig();

On Config(), it could then set SomeBool on the first occurance (loading), and then on any other occurance it would save it if the value has changed.

[ocornut]

This could totally work as separate library, calling it say, Ini::. For now it isn't a top priority/necessity for imgui, but supporting official ways of storing docking information may introduce something like that.

[codecat]

Fair enough. What about window close state? That is generally what I would intend to use it for.

[ocornut]

This idea is still up in the air (someone mentioned it to me recently) and unimplemented, but in the meanwhile here's a little update:

• imgui_internal.h now has an api for registering types to be saved/loaded in the .ini file. It's not really aimed for the end-user but rather for specific subsystems (I developed it for the docking). Interestingly what it means is that someone could implement an API for general key<>value storage and use that facility the store to the data in the .ini file.

• Mildly unrelated, but the code has been reworked to internally read/write from memory. The hooks haven't been exposed yet because there are a few open questions. but basically I expect that soonish it'll be easy to save/load the .ini data without relying on fopen. (EDIT That's now possible and exposed)

[denniskb]

+1 Just let me add my custom variables to the ini file that is already being created. ImGui::Save("UI Scale", uiScaleSliderValue);

[HenryJones14]

+1

[ocornut]

Update on this long running thread:

• (A) The topic is called "More general ini file support" which suggests an open-ended serializer, which is probably not in our scope right now because I believe it could be developed as a separate helper, but I am not ruling out tackling this.
• (B) However, the actual intent from OP, and one that I've seen in many instances is that people simply want to store the open/close state of windows, and that's a whole different feature than "General ini file support".

For (B) it would be quite trivial to save this information, but loading it would requires some mechanism for your code to query the ini data and store it in your own data/storage, which in a way would be a simplified version of (A).

I'm going to investigate this from this angle. But need to clarify that handling that state is very different from handling window pos/size/collapsed etc which is state fully owned by dear imgui.

• It would need to be partially manually handled by the app
• needs a specific API design
  • design can easily snowball into non-obvious features. Next step people want opening Feature X to restore visible state of Tools X1 and X2, but what is Feature X is not opened during that session? its a giant clusterfuck with no simple answer and ties to your own hierarchical logic/view on how windows are opened.
• it creates a situation where .ini data is at risk of (A) being constantly changing and (B) being misleading as we could store e.g. Visible=true for a given window yet it's not honored by app.

TL;DR doing this on my end even just for window visibility can easily snowball into a week-long feature to get to expected quality level. Doing it on your end will take 20 minutes if you have a serializer available.