3 ms·

It is actually quite amazing how well the idea of reusable components works for Dear ImGui which doesn't have any obvious 'extension points' for components buil

It is actually quite amazing how well the idea of reusable components works for Dear ImGui which doesn't have any obvious 'extension points' for components built into the API. Instead components are just regular functions which compose higher level UI widgets from builtin widgets and maybe dropping down into the ImDrawList renderer (which is also used by the builtin widgets to draw themselves). And just like integrating Dear ImGui itself, integrating a component is just dropping a couple of source files into your project.

itronitron 2y ago
If you are familiar with other native windowing toolkits (such as Motif, Qt, Swing) can you elaborate on how Dear ImGui takes a different approach?
- joeld42 2y ago
  ImGui doesn't have "components" like a traditional toolkit. If you want a custom component you just make a regular function like: MyCustomThing::MyWidget( "name", whatever_value ); And it gets the current rectangle from a global context, can allocate some of that rectangle space for itself, draw things, react to events, etc. It's more complicated when the widget needs to store state, but ImGui has pretty well established conventions for how to do that, which basically boils down to hashing the widget name or ID and storing your state there. And when you try, you find you need a lot less state than you might expect. Of course if you have custom data that already has state (e.g. an object passed into your widget), you can use and modify that directly which is great. It's a very different way of thinking, and it does have some challenges but it usually ends up being a lot simpler and more robust than a "retained mode" gui.
osullivj 2y ago
Yes, no extension points as you would have in a template style framework which executes canned imperative functionality around blocks of app code in a pre determined manner. ImGui is compositional, and you can compose render funcs in any order you like. Though the programming style appears imperative, the ImGui model is deeply functional, though implicitly so. IMHO Forth style threaded imperative models capture the implicitly functional model well.

itronitron 2y ago

If you are familiar with other native windowing toolkits (such as Motif, Qt, Swing) can you elaborate on how Dear ImGui takes a different approach?

joeld42 2y ago
ImGui doesn't have "components" like a traditional toolkit. If you want a custom component you just make a regular function like: MyCustomThing::MyWidget( "name", whatever_value ); And it gets the current rectangle from a global context, can allocate some of that rectangle space for itself, draw things, react to events, etc. It's more complicated when the widget needs to store state, but ImGui has pretty well established conventions for how to do that, which basically boils down to hashing the widget name or ID and storing your state there. And when you try, you find you need a lot less state than you might expect. Of course if you have custom data that already has state (e.g. an object passed into your widget), you can use and modify that directly which is great. It's a very different way of thinking, and it does have some challenges but it usually ends up being a lot simpler and more robust than a "retained mode" gui.

osullivj 2y ago

Yes, no extension points as you would have in a template style framework which executes canned imperative functionality around blocks of app code in a pre determined manner. ImGui is compositional, and you can compose render funcs in any order you like. Though the programming style appears imperative, the ImGui model is deeply functional, though implicitly so. IMHO Forth style threaded imperative models capture the implicitly functional model well.