4 ms·

> No global or hidden state Does that mean that one can detach an input field, save its state somewhere, create a new one and attach it somewhere else again an

by pka 9y ago

> No global or hidden state Does that mean that one can detach an input field, save its state somewhere, create a new one and attach it somewhere else again and have it appear exactly as it was before (i.e. cursor position, selection, focus, etc)? That's one of the pain points with VDOM frameworks (i.e. need to diff around UI components which shouldn't lose state), so I'm curious if this library gets it right.

TeMPOraL 9y ago
There is no "input field", the UI state is entirely on your end :). This is immediate mode UI. It handles inputs and renders simultaneously. Consider a line from the example in the README: nk_slider_float(&ctx, 0, &value, 1.0f, 0.1f); That line is responsible for both drawing the slider (at a place determined by value, with min = 0, max = 1, step = 0.1) and setting the variable `value` to whatever position user is currently dragging the slider to. Or: if (nk_button_label(&ctx, "button")) { /* event handling */ } That simultaneously draws the button and executes the conditional if the button was just pressed. Immediate mode GUIs are used in games, where you think in terms of drawing frames, each visible for a fraction of a second. When using such GUI, you usually "clear" it at the beginning of the frame, feed it with input from current frame, then build up the UI at the same time as you're drawing it[0]. So basically, you're in total control of the state; there is no persistent "input field", you recreate it each frame with a function call, and it's up to you whether or not it's meaningfully the same input field as it was the last frame. -- [0] - most times, like in this case, "drawing" means you "build up" a list of display commands which then you feed to the renderer at the end - this lets an immediate mode GUI be independent of whatever graphics library you're using.
- jstimpfle 9y ago
  > It handles inputs and renders simultaneously. I'm not sure that's the point. I think it's a good idea to decouple input and output (render). The point of IMGUI vs traditional toolkits is, I think, rather that you don't have to communicate through an API to manipulate and sync state with the framework/library. The latter imposes lots of communication overhead and second guessing, and can't offer the same level of control.
  - billsix 9y ago
    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...

by pka 9y ago

TeMPOraL 9y ago

There is no "input field", the UI state is entirely on your end :). This is immediate mode UI. It handles inputs and renders simultaneously. Consider a line from the example in the README: nk_slider_float(&ctx, 0, &value, 1.0f, 0.1f); That line is responsible for both drawing the slider (at a place determined by value, with min = 0, max = 1, step = 0.1) and setting the variable `value` to whatever position user is currently dragging the slider to. Or: if (nk_button_label(&ctx, "button")) { /* event handling */ } That simultaneously draws the button and executes the conditional if the button was just pressed. Immediate mode GUIs are used in games, where you think in terms of drawing frames, each visible for a fraction of a second. When using such GUI, you usually "clear" it at the beginning of the frame, feed it with input from current frame, then build up the UI at the same time as you're drawing it[0]. So basically, you're in total control of the state; there is no persistent "input field", you recreate it each frame with a function call, and it's up to you whether or not it's meaningfully the same input field as it was the last frame. -- [0] - most times, like in this case, "drawing" means you "build up" a list of display commands which then you feed to the renderer at the end - this lets an immediate mode GUI be independent of whatever graphics library you're using.

jstimpfle 9y ago
> It handles inputs and renders simultaneously. I'm not sure that's the point. I think it's a good idea to decouple input and output (render). The point of IMGUI vs traditional toolkits is, I think, rather that you don't have to communicate through an API to manipulate and sync state with the framework/library. The latter imposes lots of communication overhead and second guessing, and can't offer the same level of control.
- billsix 9y ago
  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...