Maybe I find myself making lots of buttons with similar behavior/logic/etc... So I make a helper function to eliminate the boiler-plate parts of the API.

Is that even a reasonable idea in an IMGUI context? How will you deal with the logic introduced by the immediate result values?

My impression is that if you try to do this, you will end up having to build an entire retained-mode wrapper around your IMGUI, and you'd be better off using an RMGUI in the first place.

I think so. Maybe I have a game-specific debug menu, with some XML (or, more likely, static table in code) configuration:

static DebugButtonData [] =
{
  { "GodMode", toggleGodMode },
  { "NoClip", toggleNoClip },
  { etc... }
} buttons;

for (int i = 0; i < numDebugButtons; ++i)
{
  if (DoButton(buttons[i].label))
  {
    buttons[i].callback();
  }
}

I just don't see why you wouldn't want to be able to write code like that... (Which still leads me back to the previous suggestion - pass in a string and use that (or hash it)).

I think so. Maybe I have a game-specific debug menu, with some XML (or, more likely, static table in code) configuration:

static DebugButtonData [] =
{
  { "GodMode", toggleGodMode },
  { "NoClip", toggleNoClip },
  { etc... }
} buttons;

for (int i = 0; i < numDebugButtons; ++i)
{
  if (DoButton(buttons[i].label))
  {
    buttons[i].callback();
  }
}

Now you want to introduce externally defined callback functions? This just seems like a use-case where IMGUI doesn't fit very well.

What exactly is your fancy IMGUI buying you over a RMGUI at this point? Especially if you are requiring your programmer to manually create unique (and stable) id strings for every single widget?

No, I just want to be able to use the IMGUI API without restrictions that are based on implementation details. I'm not talking about adding callbacks to the IMGUI API, but being able to write helper code in the client application to reduce boiler-plate kruft. Assuming a simple interface with DoButton, I could write the following code:

if (DoButton("GodMode"))
{
  toggleGodMode();
}
if (DoButton("NoClip"))
{
  toggleNoClip();
}
...

Yeah I already tried to say that the linenumber is useless for composite widgets that get called more than 1 time.

If you for example make a do_okcancel function you cant just let it use __LINE__ for the ok button and __LINE__+1 for the cancel button it calls, because when dialog1 and dialog2 both call that it wouldnt work then cause of same id on the second call.

Thats why I hinted already at using the parent id, because it should by definition be unique already, and mangling it with a hashfunction. Then you could call the ok button with gen_id(id,2,0) and the cancel button with gen_id(id,2,1) and it magically just works, if you found a good gen_id hashfunction.

A simple example would be like gen_id(id,n,i)=id*n+i but it only works if n is the global max for all i=(childwidgetindex inside a widget) in all widgets and its guaranteed that it never overflows and nowhere a conflicting id is generated. I would encourage you to find a better one yourself. (I currently use some other, but it is more complicated and in some aspects better, in others possibly worse.)

The ID is known at compile time, and in my case, I have a "std::vector<widget> DrawQueue" that I push widgets on with drawing information. I loop through this vector later at draw time for batching. This decouples the drawing and the interaction with the widget.

Nothing is stopping you from adding more data to the widget structure that gets added to the DrawQueue. A helper function could look for the widget with a certain ID and respond to whatever states are in that widget instance.