User-defined IDs for ImGuiCol and ImGuiStyleVar

[eugeneko]

I want to be able to use arbitrary IDs for color and non-color variables in ImGUI for custom widgets.

Use case:

Let's say I am making MyMagicWidget which uses three colors to render text: ImGuiCol_Text, ImGuiCol_TextDisabled and MyMagicTextColor. I want users to configure my widget freely.

Users already can configure ImGuiCol_Text and ImGuiCol_TextDisabled just fine with current ImGUI API, but I have to create custom API and interface to let users configure MyMagicTextColor, which creates inconsistency in API.

There's no conceptual difference between e.g. ImGuiCol_TableHeaderBg and MyMagicTextColor, these are both just colors used by some widgets. It would be nice to have color stack feature available for both of them.

@rokups

[rokups]

Not sure about arbitrary IDs, but there could be some mechanism of extending ImGuiStyleVar_ + ImGuiCol_ with some space reserved for users. Adding more colors to ImGuiStyle::Colors would be trivial. Its a bit more involved with style vars storage since we can store either 1 or 2 floats for each var.

We could have a build time define in imconfig.h defining how many custom extra colors are allowed in the style and then enum becomes

enum ImGuiCol_
{
    // ...
    ImGuiCol_ModalWindowDimBg,
    ImGuiCol_USER_START,
    ImGuiCol_COUNT = ImGuiCol_USER_START + IM_USER_STYLE_COLOR_COUNT
};

Then users would have to define their constants for style colors which would be ImGuiCol_USER_START + N. Same thing for style vars.

[eugeneko]

I think it's okay to restrict usage to consecutive IDs, but I don't really like fixed-size solution. You can just add dynamic ImVector tail for all IDs >= ImGuiCol_COUNT tho. You will have to add some branching, but it shouldn't be too many places.

[ocornut]

The ID would need to allow some form of dynamic registration in order to allow for multiple extensions adding their, a static scheme wouldn't be useful enough.

[rokups]

I threw this together to test the idea: https://github.com/ocornut/imgui/compare/master...rokups:imgui:rk/user-defined-style-colors

[eugeneko]

@ocornut although dynamic registration is a boon, I would argue that static usage is good enough in many cases. The only real conflict point are names, and I don't really need names to use UI, I need them only for tooling.

As long as I don't need names, there's no issue in conflicting IDs. If both Widget1 and Widget2 use color IDs 100, 101, 102, I just need to fill them right before using the widget. And if I want to embed Widget1 and Widget2 into my own widget, I will probably want to use my own color IDs on the top level, and remap them to Widget1-IDs or Widget2-IDs internally.