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);