ocornut
Feature Suggestion: Save and Load functions for ImGuiStyle struct
Version/Branch of Dear ImGui:
current docking branch
Back-ends:
any
Compiler, OS:
all
Full config/build information:
No response
Details:
I have recently come to the realization that the only reliable way to have an ImGuiStyle set on application load is via hard coding the style into the source code. Recent commits made updating the ImGuiStyle struct have invalidated just writing the ImguiStyle struct to file and then reloading it. Which was my admittedly short sighted shortcut to saving the styles, made using the demo ImGuiStyleEditor, for later use in applications made using ImGui.
Currently outside of hard coded themes, theming imgui and sharing a theme is really not possible. I would like to help fix this.
See issue #707 , there is no way to save and load themes, and while people have wrote partial ImGuiStyle save and load functions, none cover the whole struct. Much less since there not part of the imgui code base it requires managing another git submodule for handling what could be handled by imgui for its own struct.
I would be happy to create a pr with a suggested solution, but serializing the data requires some standardization to the approach of how the ImGuiStyle struct would be updated in the future. To allow loading of older saves, there would need to be a save version for instance saved with the struct.
My initial thoughts on how it could work going forward is if, new style and colors are always added to the end of the struct, with the colors always being at the end, then the load function when loading an older version would only have to move the old colors via memcopy to the correct position and initialize all new style and color variables in the struct. This solution while simple has the downside of updates to the ImGuiSyle struct would over time possibly ungrouping the related styles as everything is just tacked on to the end, making the imgui.h header less readable.
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
theming imgui and sharing a theme is really not possible.
It is possible, as you just linked to a thread with plenty of shared themes.
My initial thoughts on how it could work going forward is if, new style and colors are always added to the end of the struct
This would be very inacceptable. However the function GetStyleColorName() was added exactly for the purpose of avoiding to save anything unkeyed. You can store that name (or a hash of it) along with colors data to allow forward-compatible loading of the data (eg Name = Value).
If you need to save other settings (sizes, paddings) because you want them to be user configurable, simply add yourself a name table (eg { “FramePadding”, ImGuiStyleVar_FramePadding } and the rest may be done programmatically.
I don’t agree with the premise that we should encourage binary storing style data, even less so considering the style system is currently limited, bound to evolve, and that keeping source code flexible is the most important property to strive for.
I actually currently don’t even agree with the premise that we should encourage people sharing styles so much. The system is too limited and sharing colors + fonts is enough. Much of what makes an application good looking is due to subtler work which is not part of the style but of code, eg using icons, changing text color, varying fonts. Hopefully more will become part of style when I get to tackle an hypothetical style v2 system.
Issue #707 shares code for hard coding a theme, and one link to an incomplete theme saving and loading functions. There is no way to allow for changing to a theme not already hard coded into an application using ImGui without wrapping the ImGuiStyle struct yourself. Again my issue is not sharing hard coded themes, it that themes are not portable, after compiling.
Yes GetStyleColorName helps with the colors, but that does not cover anything else, or all the other style vars, and 1 enum in the struct.
I would hard disagree that a save and load function kills flexibility, it rather centralizes the code responsible for saving and loading the ImGuiStyle struct back to ImGui instead of every project wrapping it if they want this functionality. Weather you save it in a straight binary form or key value pairs, all I was looking for is to put the save and load function with the struct in ImGui where it arguably belongs.
From a maintainers standpoint if someone was to add something to the Style struct they would then be responsible for incermenting the version value and adding key value pair to save func(assuming key value pair since you seem to be against binary dump) and to the load function a if (version > valueinsave) init new sytlevar or color along with setting the version number to the current version.
Again my offer to help write this functionality still stands, I opened this issue to see if your interested and if so what requirements you would put on the system. I totally understand if you still are not interested in this or maintaining this, please close the issue if so.