[amluto]

Here’s a downside that wasn’t mentioned:

    if (ImGUI::Button("Click Me")) {
        IWasClickedSoDoSomething();
    }

This forces Button to be stateless, which limits the possible quality of implementation. If you mouse-down on a button and the button changes before you mouse-up, it shouldn’t register as a click. Similarly, if you mouse-down on a button, drag to the button, and mouse-up, it shouldn’t be a click. Implementing this in a fully immediate-mode GUI with this interface is either impossible or requires gross hacks.

[bdowling]

A naive implementation would have the problem you describe. However, a smarter library implementation avoids this (e.g., by generating an id for the button, saving the id on mouse-down, and checking the id on mouse-up). The user of such a library won't have to worry about it.

[amluto]

And how, exactly, is the id created? Some hash of the button’s text and coordinates?

I would call that a dirty hack, no to mention being implicitly stateful.

[HelloNurse]

But a stateful GUI is not a sin: the program as a whole has state, application code needs to process GUI inputs to update application-level state (e.g. currently set game options) while tracking mechanical details like whether a button is "half clicked" is suitable for automation at the GUI library level.

Regarding IDs, they can (and must) be provided by client code, as client code is responsible for managing widget identity (i.e. whether the button that might have a mouse up event this frame is "the same" that received a mouse down event some frames ago). In C or C++, string names could usually be autogenerated with trivial macros relying on __LINE__ and __FILE__.

[Larowyn]

That's not how it would go, you don't need state to handle different events, in the case you describe the button is not clicked, of course the button would not trigger on anything else than a mouseup that would be incredibly dumb. It will go something like this: - The mouse is on top of the button, you could render your button differently with that information. - The mousdown event trigger on top of the button again you can do something to make the button render differently. - If the mouseup event occur the button trigger. Instead of keeping a state on your button you render your uis elements conditionned on the cursor position and state of the mouse (up or down)