4 ms·

This isn't true. All state you need to keep track of is purely the input state: e.g. whether a button is pressed, keys are pressed, etc. And very importantly,

This isn't true. All state you need to keep track of is purely the input state: e.g. whether a button is pressed, keys are pressed, etc. And very importantly, you also need to store the edges of the input signal. That is, you need to store whether left mouse has changed from not pressed to pressed this frame, and whether it has changed from pressed to not pressed. Then, the Button(...) call computes the hitbox of the button, checks whether the left mouse button has changed from 'not pressed' to 'pressed' this frame, and if yes, whether the mouse coordinates are inside the hitbox. If yes, it returns True, else it returns False. No widget state needs to be kept.

Jasper_ 6y ago
There's a bit more subtlety than that. If I press down on a button, then move my mouse off of it, it will be deselected. This is normal and not too hard to implement your model. But, if I keep my mouse button held down, and drag back on, it will become re-highlighted, and it will go through. Note that only the button I originally clicked on will have this behavior. I just tested this right now in the ImGUI demo, so clearly per-widget state is tracked (or at least which "widget" is the one that has the mouse's active state): https://github.com/ocornut/imgui/#demo https://github.com/ocornut/imgui/#demo If you think this is obscure, try implementing a slider widget any other way. You need a way to keep track of which slider you were dragging, even when the mouse cursor leaves to another.
- nightcracker 6y ago
  This is solved by the exact same state I mentioned earlier. The only thing I need to make explicit is that you store the mouse coordinates of each event type with that event, for later retrieval. E.g. `events['mouse_down_edge']` stores a tuple `(frame_nr, coords)`. Then you know that we are dragging this slider if the mouse is held down, and its initial down edge in the signal was generated while hovering over this slider. --- For what it's worth, I know that (some parts of) dear ImGUI are not implemented in the above way, and instead do keep track of some widget state with labels and unique ids. People however heavily overestimate to what extent this is necessary.
flohofwoe 6y ago
At least in the case of Dear ImGui, things like the current window position and size is widget state that's owned and persisted between frames by the library, otherwise windows wouldn't be moveable or resizeable by the UI user. Other immediate mode UIs may decide to delegate this "state housekeeping" to the user (that's how rxi's microui works), but IMHO this isn't quite as convenient for the library user, it keeps the library implementation very simple though.
formerly_proven 6y ago
> No widget state needs to be kept. This is correct. Windows (which includes things like popups and dialogs) have "state behind your back", but widgets generally don't - at least I've never seen it in the code. 99 % of the examples given by other commenters are not handled by hidden widget state, but by g.activeID. As someone pointed out, changing IDs in the middle of an interaction is problematic for that reason (not because imgui fails to find the widget in its hidden tree of widgets, which doesn't exist).

Jasper_ 6y ago

There's a bit more subtlety than that. If I press down on a button, then move my mouse off of it, it will be deselected. This is normal and not too hard to implement your model. But, if I keep my mouse button held down, and drag back on, it will become re-highlighted, and it will go through. Note that only the button I originally clicked on will have this behavior. I just tested this right now in the ImGUI demo, so clearly per-widget state is tracked (or at least which "widget" is the one that has the mouse's active state): https://github.com/ocornut/imgui/#demo https://github.com/ocornut/imgui/#demo If you think this is obscure, try implementing a slider widget any other way. You need a way to keep track of which slider you were dragging, even when the mouse cursor leaves to another.

nightcracker 6y ago
This is solved by the exact same state I mentioned earlier. The only thing I need to make explicit is that you store the mouse coordinates of each event type with that event, for later retrieval. E.g. `events['mouse_down_edge']` stores a tuple `(frame_nr, coords)`. Then you know that we are dragging this slider if the mouse is held down, and its initial down edge in the signal was generated while hovering over this slider. --- For what it's worth, I know that (some parts of) dear ImGUI are not implemented in the above way, and instead do keep track of some widget state with labels and unique ids. People however heavily overestimate to what extent this is necessary.

flohofwoe 6y ago

At least in the case of Dear ImGui, things like the current window position and size is widget state that's owned and persisted between frames by the library, otherwise windows wouldn't be moveable or resizeable by the UI user. Other immediate mode UIs may decide to delegate this "state housekeeping" to the user (that's how rxi's microui works), but IMHO this isn't quite as convenient for the library user, it keeps the library implementation very simple though.

formerly_proven 6y ago

> No widget state needs to be kept. This is correct. Windows (which includes things like popups and dialogs) have "state behind your back", but widgets generally don't - at least I've never seen it in the code. 99 % of the examples given by other commenters are not handled by hidden widget state, but by g.activeID. As someone pointed out, changing IDs in the middle of an interaction is problematic for that reason (not because imgui fails to find the widget in its hidden tree of widgets, which doesn't exist).