Ryan,

You cannot really "package" ImGui (in the sense of building binaries or storing it in /usr/lib as opposed to application side). The reason imconfig.h exists and appears to be intrusive is to allow the user to replace things like the ImVector implementation, adding conversation operators to the math types, potentially changing the vertices layouts. For those things Imgui.cpp needs to be compiled in with imconfig.h and in this context I believe the current system is correct.

I appreciate the intent but I don't have a solution to it and I think imgui is best not "packaged". The files can be copy & pasted into projects rather than attempting to make it a shared library. This is also why imgui is designed to be so few files and I think it also empower the individual developer to just hack in the files at ease to add what they need instead of feeling constrained.

Okay, that sounds about right. I didn't realize that imconfig.h needed to be available at compile time for imgui.cpp.

However I have one more question. Would it be okay for imconfig.h be included in imgui.cpp, and not imgui.h by default?

What would be the purpose / benefit of doing that ?
imconfig.h has potential effect on data structures exposed in imgui.h so it would be expected that the user include it.

Part of the design is that I want the end-user to use imgui in a random file using 1 include to minimise "setup", because imgui is as much a debug tool than it is a ui library - you can use it to quickly log stuff or edit stuff. So for example you can use Text function to trace an algorithm in a file that has nothing to do with UI.

#include <imgui.h>
...
ImGui::Text("Log some stuff");

So the overhead is reduced to 1 include, and this is why there is an implicit Begin/End pair in ImGui so you can use the widgets and they go in a default window, saving 2 extra lines of overhead.

Oh okay, now I understand. This library is primarily for quick debuging and logging; and not really GUI-focussed (other than to give developers quick access to logging info).

Anways, thank you for your time. And, thank you for explaining it to me.

"as much a debug tool than it is a ui library" doing both.
No worry, I realised it is a bit of an oddity compared to more standardized library. Avoiding the need for binary release is an important part of the design because they require maintenance and often not compatible between os or compiler versions (Windows+Visual Studio in particular are terrible with that). This create an adoption wall - lots of otherwise interesting code fitting niches are ignored because trying them is a hassle. So the focus is on making it trivial to just compile Imgui yourself.