Dear ImGui code actually looks quite declarative, except that the actions are directly 'inlined' into the UI declaration as code.
For instance:
if (ImGui::Button("Click Me")) {
// do the stuff that should happen when the button is clicked
}
To hide a part of the UI you simply skip the code which describes that part of the UI.
if (!btnHidden) {
if (ImGui::Button("Click Me")) {
...
}
}
Your code describes what the UI should look like in the current frame, and what should happen on user interactions, but without event listeners or callback functions.
How you keep the UI declaration separate from the "business logic" is up to you. Dear ImGui allows very close coupling (which quite often is actually an advantage for adhoc UIs), or you can keep both separated as much as you prefer.
> How does IMGUI handle theming, reflow or even GPU acceleration on different platform ?
Dear ImGui actually builds an internal "stateful" representation of the UI declaration (it needs to remember at least some state between frames, otherwise simple features like moveable/sizeable windows wouldn't be possible) and then generates an optimized list of rendering commands that plug almost directly into 3D rendering APIs like D3D, Metal, GL etc... (the renderer is implemented outside of Dear ImGui by yourself, however Dear ImGui also comes with pluggable example renderers and window system glue for pretty much any platform and 3D API).
Themeing/skinning is indeed a weak point of Dear ImGui specifically, other immediate mode UI frameworks like Nuklear offer more flexibility there, but this has nothing to do with the imgui philosophy, only with feature sets of specific imgui libraries.