3 ms·

When you say, draw a button in an immediate mode gui, the widget is drawn for this frame, which has not yet been flushed to the monitor. Yet the draw button fu

When you say, draw a button in an immediate mode gui, the widget is drawn for this frame, which has not yet been flushed to the monitor. 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? The imgui framework handles the previous frames events when drawing the current frame. This implies that the only concept you really need to know using an immediate mode GUI framework, is that internally to the framework it needs some mechanism to identify objects between frames.

jstimpfle 9y ago
> the only concept you really need to know using an immediate mode GUI framework, is that internally to the framework it needs some mechanism to identify objects between frames. So why not allocate the necessary structures on the caller-side, and hand them as arguments to update and render calls? I think that's cleaner. It's the way I've started going forward for my own experiments. I briefly looked into Dear Imgui before, and I was thinking it had quite a few hacks to find the objects from last frame. Lots of best effort guessing and workaround schemes to keep the API calls "concise".
- billsix 9y ago
  I think overall you and I agree quite a bit. But as far as I can tell, nuklear is designed to be simple to program the implementation, and simple to program against, at the cost of some features. https://github.com/vurtun/nuklear/issues/50 https://github.com/vurtun/nuklear/issues/50 Dear imgui may have some hacks as you mention to achieve features such as using tab to switch the active component, (I've never looked at the source), but it's still simple as can be to use. I'm not quite sure what you're advocating to do, but if you make a better graphical user interface framework than those other two projects, then I can't wait to see it.
  - jstimpfle 9y ago
    Always happy to find people to connect to and talk about how to actually _make_ infrastructure instead of only using it. (Maybe it's not brainy or sexy enough?) I've only begun making some UI elements. At the moment I have a keyboard-driven menu, and a slider box and an unused button with misplaced caption that react to mouse clicks. There's a lot more infrastructure I've experimented with and the UI just barely works -- but I'll soon need and work on more 2D UI functionality. One problem is that I'm not sure how to structure 2D rendering, having to deal with modern OpenGL. But I need this experience to inform my UI architecture. I will probably study vurtun a bit. So if you're interested check back in two weeks (and I'm happy to receive feedback). https://github.com/jstimpfle/learn-opengl/blob/master/ui.c https://github.com/jstimpfle/learn-opengl/blob/master/ui.c https://github.com/jstimpfle/learn-opengl/blob/master/meshview.c https://github.com/jstimpfle/learn-opengl/blob/master/meshvi...
    - billsix 9y ago
      Sounds good. I too have a 3d graphics playground app if you're interested https://github.com/billsix/hurtbox https://github.com/billsix/hurtbox
mellinoe 9y ago
> 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).

jstimpfle 9y ago

> the only concept you really need to know using an immediate mode GUI framework, is that internally to the framework it needs some mechanism to identify objects between frames. So why not allocate the necessary structures on the caller-side, and hand them as arguments to update and render calls? I think that's cleaner. It's the way I've started going forward for my own experiments. I briefly looked into Dear Imgui before, and I was thinking it had quite a few hacks to find the objects from last frame. Lots of best effort guessing and workaround schemes to keep the API calls "concise".

billsix 9y ago
I think overall you and I agree quite a bit. But as far as I can tell, nuklear is designed to be simple to program the implementation, and simple to program against, at the cost of some features. https://github.com/vurtun/nuklear/issues/50 https://github.com/vurtun/nuklear/issues/50 Dear imgui may have some hacks as you mention to achieve features such as using tab to switch the active component, (I've never looked at the source), but it's still simple as can be to use. I'm not quite sure what you're advocating to do, but if you make a better graphical user interface framework than those other two projects, then I can't wait to see it.
- jstimpfle 9y ago
  Always happy to find people to connect to and talk about how to actually _make_ infrastructure instead of only using it. (Maybe it's not brainy or sexy enough?) I've only begun making some UI elements. At the moment I have a keyboard-driven menu, and a slider box and an unused button with misplaced caption that react to mouse clicks. There's a lot more infrastructure I've experimented with and the UI just barely works -- but I'll soon need and work on more 2D UI functionality. One problem is that I'm not sure how to structure 2D rendering, having to deal with modern OpenGL. But I need this experience to inform my UI architecture. I will probably study vurtun a bit. So if you're interested check back in two weeks (and I'm happy to receive feedback). https://github.com/jstimpfle/learn-opengl/blob/master/ui.c https://github.com/jstimpfle/learn-opengl/blob/master/ui.c https://github.com/jstimpfle/learn-opengl/blob/master/meshview.c https://github.com/jstimpfle/learn-opengl/blob/master/meshvi...
  - billsix 9y ago
    Sounds good. I too have a 3d graphics playground app if you're interested https://github.com/billsix/hurtbox https://github.com/billsix/hurtbox

mellinoe 9y ago

> 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).