5 ms·

> Yet the draw button function returns true or false on whether it was clicked. But how can that be, this button has not yet been flush to the display? A butto

> Yet the draw button function returns true or false on whether it was clicked. But how can that be, this button has not yet been flush to the display? A button being clicked doesn't really have anything to do with whether it's been drawn or not. The relevant information is whether the user has hovered the button with their mouse and (mouse position), and whether the mouse button is pressed (mouse button state), both of which are usually provided to the system on a per-frame basis. I've not used Nuklear, but this is how dear imgui works. If the GUI system knows where you are clicking, and must know the position of the button it's drawing (in order to render it), then it should be able to tell if it's being pressed.

skybrian 9y ago
Nice, but what about a double-click, long press, or drag? Is it just about detecting whether an input button is currently down, or is there some way to handle a gesture happening over time?
- mellinoe 9y ago
  At least in dear imgui, the input information is provided every frame, so the system can track it over time. If you want to see if there was a double click, then you can call "IsMouseDoubleClicked", for example.
billsix 9y ago
I am unsure about where we disagree. What you quoted from me was a set up for my subsequent, unquoted argument. Buttons don't fly around the screen over time. If a user clicked on the screen 1.0/144 seconds ago (assuming a 144 htz monitor), the user likely clicked on the button which is about to be redrawn.
- mellinoe 9y ago
  I guess I don't understand why this would be true: > The imgui framework handles the previous frames events when drawing the current frame. I'm not terribly familiar with the inner workings of these libraries, though, so I could be wrong. Since you pass in the input state for each frame, it's my understanding that they just process the current frame's "events" during that frame. It would be a little weird if you passed some mouse click event into the system and your Button() call returned true the NEXT frame (I think that's what you're suggesting).
  - billsix 9y ago
    That is what I'm suggesting. Before I used immediate mode GUIs, I was familiar with using Qt, wx, and gtk. Never did X windows. So I never handled events directly, just indirectly programmed what would happen upon the event occuring. I had been under the likely incorrect assumption that those frameworks, in order to correctly associate say a mouse click to a button, had a mapping of the previous frame's screen-space coordinates of all widgets, and when a click happened, they associated the click with the previously drawn widget. Because that is what was on the screen when the mouse was clicked. Immediate mode GUIs baffled me. How could the drawing of a button, which has not yet been flushed to the monitor, return true or false depending upon whether or not it was clicked? The button is not yet on the monitor!!! After thinking about it for 10 minutes, buttons don't fly all over the screen. Whatever the bounding box for the button for this frame is likely the bounding box it had last frame. So the association is easy, assuming the imgui framework can keep track of object identity across frames. Perhaps, I am just ignorant of how qt, gtk, and wx, actually work.

skybrian 9y ago

Nice, but what about a double-click, long press, or drag? Is it just about detecting whether an input button is currently down, or is there some way to handle a gesture happening over time?

mellinoe 9y ago
At least in dear imgui, the input information is provided every frame, so the system can track it over time. If you want to see if there was a double click, then you can call "IsMouseDoubleClicked", for example.

billsix 9y ago

I am unsure about where we disagree. What you quoted from me was a set up for my subsequent, unquoted argument. Buttons don't fly around the screen over time. If a user clicked on the screen 1.0/144 seconds ago (assuming a 144 htz monitor), the user likely clicked on the button which is about to be redrawn.

mellinoe 9y ago
I guess I don't understand why this would be true: > The imgui framework handles the previous frames events when drawing the current frame. I'm not terribly familiar with the inner workings of these libraries, though, so I could be wrong. Since you pass in the input state for each frame, it's my understanding that they just process the current frame's "events" during that frame. It would be a little weird if you passed some mouse click event into the system and your Button() call returned true the NEXT frame (I think that's what you're suggesting).
- billsix 9y ago
  That is what I'm suggesting. Before I used immediate mode GUIs, I was familiar with using Qt, wx, and gtk. Never did X windows. So I never handled events directly, just indirectly programmed what would happen upon the event occuring. I had been under the likely incorrect assumption that those frameworks, in order to correctly associate say a mouse click to a button, had a mapping of the previous frame's screen-space coordinates of all widgets, and when a click happened, they associated the click with the previously drawn widget. Because that is what was on the screen when the mouse was clicked. Immediate mode GUIs baffled me. How could the drawing of a button, which has not yet been flushed to the monitor, return true or false depending upon whether or not it was clicked? The button is not yet on the monitor!!! After thinking about it for 10 minutes, buttons don't fly all over the screen. Whatever the bounding box for the button for this frame is likely the bounding box it had last frame. So the association is easy, assuming the imgui framework can keep track of object identity across frames. Perhaps, I am just ignorant of how qt, gtk, and wx, actually work.