4 ms·

About the IMGUI Paradigm

58 points by ibobev 2y ago

zzo38computer 2y ago
> The structure and function of your UI is naturally expressed in the code of the functions that draw it, instead of in ephemeral and opaque object trees that only exist in RAM after they're constructed at runtime This is probably it (although perhaps it is not quite the best explanation, but the example in the article helps to explain it); there are many possible implementations of an idea such as this. However, depending on the program and on other stuff, it is not always best for all kind of programs and all kind of UI. (In some cases, a kind of hybrid might do.) And, as they say about the example, there are things to criticize about it. Still, it can show an example of its use, even though it is a simple example. I had made my own variant of IMGUI. It uses a "win_form" block, which can be nested and which supports "break", and various other commands inside of the win_form block such as "win_command", "win_numeric", "win_boolean", etc; these commands do not have to be directly but can also be inside of a "if", "for", "switch", etc. These are implemented by C99 macros. The amount of state is small, not more than twenty bytes per active form (regardless of the number of widgets), and it is stored in the stack (but there is no need to explicitly add commands to declare or allocate this state; the "win_form" macro does this automatically). The git repository https://github.com/zzo38/superzz0 https://github.com/zzo38/superzz0 is for a program that contains this UI implementation. The file called "common.h" contains the macros and function declarations, and "window.c" contains the implementation. You can see many uses of it in "edit.c" (search for "win_form" to find many of the uses). As they say in the article, immediate mode does not necessarily mean that the library doesn't retain data (mine retains a single pointer, which is used to restore state when leaving a nested win_form block), that it needs a GPU to render, etc.
- Zecc 2y ago
  For some reason your comment shows as having been posted 6 days ago (or 8 days ago when editing my reply) even though this thread was created only 3 hours ago. What is happening here?
  - coryrc 2y ago
    Sometimes submissions that don't get traction originally get merged into a more recent one that becomes popular. Though... `past` link doesn't show anything else, but that might be because it was merged?
  - zzo38computer 2y ago
    I don't know. I know I wrote it many days ago and not today, but on my computer it says 8 days ago on the /threads list but on this list it says 6 days.
bgribble 2y ago
I love the developer experience of Dear ImGUI, even though I use it through Python wrappers that confuse things sometimes. It just slices like a sword through several layers of often-pointless abstraction and puts the control over the main loop right in your hands. And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.
- krapp 2y ago
  It should be the go to for general purpose cross-platform application UI development (instead of Electron,) and it's unfortunate that something so good and so useful is only meant for debuggers and editors.
  - tom_ 2y ago
    On the flip side, targeting developers tightens the scope quite a lot! If nothing else, it massively increases the chance your target audience can at least get by with left-to-right text and 7-bit ASCII... Cornut recently did a 10 year retrospective of Dear ImGui: https://github.com/ocornut/imgui/issues/7892 https://github.com/ocornut/imgui/issues/7892 - an interesting read for me, as a Dear ImGui library user for many years now, but worth your time I think even if you aren't a user yourself. There is a specific section about the scope of the library: https://github.com/ocornut/imgui/issues/7892#issuecomment-2291436235 https://github.com/ocornut/imgui/issues/7892#issuecomment-22...
  - fassssst 2y ago
    Only if you don’t care about accessibility and common controls.
    - krapp 2y ago
      You might have a point about accessibility, but what common controls does Dear IMGui lack? It has just about every control I can think of.
      - 2y ago
amelius 2y ago
Say I have a very long listbox containing thousands of items, and each item has a height that may be different (e.g. a list of font families where each line may have a slightly different line height). How would IMGUI perform the drawing, given the scrollbar is at (say) 20%?
- deleted 2y ago
  [deleted]
- tom_ 2y ago
  I'm not sure I've ever used any library that goes to any particular effort to support this sort of thing. The standard assumption for listboxes is that every row has the same height. So you'd probably handle it the same way you would with any other system: accept that there'll be some effort involved, and get the library to do the remainder for you. So, probably, something like let the library know the total height of the contents, have it look after the viewport height and scroll bar position for you, and then draw the viewport contents as required.
  - loic-sharma 2y ago
    Your browser goes through extraordinary lengths to support this sort of thing.
    - tom_ 2y ago
      I guess I just got old at some point. I simply don't think of web browsers as relevant when it comes to programming.
- troad 2y ago
  I feel like I must be missing something here. Why not store the ID of the top-most visible list item, and just render the next n until you run out of box height? Surely you're not trying to draw thousands of items that aren't even visible on screen?
- badsectoracula 2y ago
lylejantzi3rd 2y ago
> they are different interpretation of what IMGUI means? Yes. Good luck clearing that up. The programming community as a whole couldn't even get Object Oriented Programming right. It originally meant little machines passing messages to each other (Smalltalk, Objective-C). What we got was inheritance, encapsulation, and polymorphism (Java).
- igouy 2y ago
  > It originally meant "Smalltalk encourages well-factored designs through inheritance. Every class inherits behavior from its superclass … all forms of ordered collections in the system will instantly acquire this new capability through inheritance." "Modularity: No component in a complex system should depend on the internal details of any other component." "Polymorphism: A program should specify only the behavior of objects, not their representation." 1981 "Design Principles Behind Smalltalk" Daniel H. H. Ingalls https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
ogogmad 2y ago
Are there GUI builders like for VB6, but for IMGUI libraries?
- gyomu 2y ago
  Posted last week: ImRAD is a GUI builder for the ImGui library https://news.ycombinator.com/item?id=41261426 https://news.ycombinator.com/item?id=41261426
malkia 2y ago
On the other hand, flutter has plenty of state management options :) - https://docs.flutter.dev/data-and-backend/state-mgmt/options https://docs.flutter.dev/data-and-backend/state-mgmt/options - it's like living in the US, you don't like how your state is managed - move to the next one!
jesse__ 2y ago
Somewhat of a nitpick.. > The acronym is misleading because "immediate-mode" was initially coined as a reference to obsolete graphics API which made it very easy to render contents. Is that actually true? From what I remember of hearing Casey (the person who coined the term) talk about it on Handmade Hero and various other streams, it's differentiating between 'immediate mode' and 'retained mode' GUI APIs (QT, GTK, Swing, MFC .. etc) which make you retain handles to UI elements. AFAIK it didn't have anything to do with the graphics API whatsoever ..? Right? EDIT: Watched the video linked of Casey from 05, which I'd never seen before and was quite interesting. I'm not totally convinced that the small portion he talked about renderer APIs near the 10 minute mark substantiates the claim, but it might.
- bob1029 2y ago
  https://learn.microsoft.com/en-us/windows/win32/learnwin32/retained-mode-versus-immediate-mode https://learn.microsoft.com/en-us/windows/win32/learnwin32/r... I think you could also draw some analogies between server side and client side rendering. Where the authoritative view state lives is the most important bit I think.
- phire 2y ago
  Yes, it's true. Direct3D had a retained mode up until version 3.0, but the only examples of it ever being used in a commercially successful game was LEGO Island and LEGO Rock Raiders. Instead of supplying all the draw commands every frame, you would give it your 3D scene and it would draw it.
  - badsectoracula 2y ago
    I tried to use it (for fun) at some point but the API design felt too verbose/cumbersome for what it did and by the time DrawPrimitive was added in D3D5 it was simpler to use that directly than use D3DRM. It was also very clear that D3DRM was designed by a different team than D3DIM.
  - torlok 2y ago
    All modern graphics APIs are retained mode, because you push data to the GPU and the GPU maintains its own state. The closest you can get to immediate mode is OpenGL 1.0 with glBegin, etc.
badsectoracula 2y ago
One of my perverse ideas for a project is to make a Dear ImGUI (the most common IMGUI library and basically what many people associate with "ImGUI") backend for Lazarus/LCL (the most non-IMGUI/Retained mode framework you can probably think with OOP -something that IMGUI aficionados seem to have a distaste for- layers thick enough to act as armor :-P).
akira2501 2y ago
> "Minimize state synchronization." > void UpdateUI() Minimize state synchronization by effectively synchronizing state on each screen refresh? > "Minimize state storage on user side." > Immediate mode is a style of API where important state is kept in user code Then reduce state stored in user code by storing "important state" in user code? > "Minimize setup and maintenance." I don't find the example convincing. It seems like any more complexity beyond this toy example puts you right back where you started. Building components by hand is stone age ideology regardless of how you push state. https://github.com/ocornut/imgui/blob/master/examples/example_allegro5/main.cpp https://github.com/ocornut/imgui/blob/master/examples/exampl... > "Easy to use to create dynamic UI which are the reflection of a dynamic data set." Which is great for a video game.
- tom_ 2y ago
  Try it! Worst thing that'll happen is that you'll still hate it.
d--b 2y ago
> Nowadays I am starting to believe that the term has caused more harm than benefits, because it suggests there are two camps "IMGUI" vs "RMGUI". The reality is there is a continuum of possibilities over multiple unrelated axises. > The fact that we are even trying to put an official definition to a label is hindering people's imagination about the many possible areas of researches to be done in UI space. Well said, but then the author proceeds and lists what IMGUI is and what it’s not. My opinion is that we may just think about IMGUI as “the stuff that dear-imgui does”, which people understand well. And yes there’s a loop, and things get redrawn all the time and so on. Everything else that borrows concepts from that is IMGUI-ish. I for myself definitely use some IMGUI concept when I do js apps, but is it imgui? Definitely not. Is it imgui-ish, hell yeah. Trying to make the term IMGUI mean “good way of doing UI” is not gonna work…
- torlok 2y ago
  It sucks that this is what immediate mode got reduced to. If you listen to what Casey was advocating for, it was to avoid the need to synchronise state between local state and black box state. This can be applied to UI, but just as well to f.e. a physics engine, where a constraint can live as long as you keep calling doConstraint(). Unfortunately, all people seem to have gotten out of that was if(doButton(...)).
- theamk 2y ago
  There maybe a continium in games space, but in non-game apps it's all crystal clear and sharp boundaries: Can the app stop generating wakeup interrupts and let CPU/GPU sleep? Yes -> this means app events (like network transfer) need to be able to generate "update" events, which means those events need to be directed somewhere, which means retained mode. No -> this means GUI is allowed to poll non-stop and thus can check every variable 60 times per second to support immediate mode.
  - modeless 2y ago
    Immediate mode and polling are not the same thing. With Dear ImGui you own the event loop so you can draw as frequently or infrequently as you want. It is not necessary to draw 60 times per second when nothing is happening. Dear ImGui's sample code currently does draw every frame even when nothing is happening. Omar has said that he would eventually like to change this and it's on his roadmap, but it's low priority because he is currently targeting game industry users and doesn't want to attract a lot more users in other areas that will add to his support load and dilute his focus. [1] He also has said the same thing about accessibility and fancy theming. These features are good examples of why "the stuff that dear-imgui does" is not a good definition of immediate mode. People often assume that anything Dear Imgui doesn't do is hard or impossible for any immediate mode API, but that's far from the truth. Omar is only one guy. He has a target audience in mind and is not trying to satisfy all use cases at once. You have to remember that when comparing Dear ImGui to a framework like Qt or SwiftUI or whatever that has hundreds if not thousands of developers contributing to it. [1] https://github.com/ocornut/imgui/issues/7892 https://github.com/ocornut/imgui/issues/7892
dsp_person 2y ago
> IMGUI does not mean it needs to refresh all-or-nothing. The author of microui described an interesting approach to this here https://rxi.github.io/cached_software_rendering.html https://rxi.github.io/cached_software_rendering.html
pjmlp 2y ago
Basically, it is how we did graphics programming back in MS-DOS, UNIX framebuffers, and everywhere else where desktop OSes didn't had a GUI framework to start with.
sweeter 2y ago
I hate writing GUI's, I cannot get them to "click" with me, but for some reason the immediate mode GUI paradigm makes a lot more sense to me. It doesn't help that UI code is usually really blocky and error prone either, but IMGUI and GIO are great
- giovannibonetti 2y ago
  Working with GUIs really "clicked" with me when I learned the Elm programming language and framework for building web applications (front-end) [1]. The Model-View-Update paradigm matches very well the UML state machine modelling taught in universities [2]. [1] https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/ [2] https://en.wikipedia.org/wiki/UML_state_machine https://en.wikipedia.org/wiki/UML_state_machine
0x1ceb00da 2y ago
One thing I never figured out how to do in an immediate mode system is encapsulating functionality. In a retained mode system I can have, for example, a panning view widget, which wraps another widget and allows you to pan and zoom using the mouse. How would one encapsulate such functionality with an immediate mode ui toolkit?
- dsp_person 2y ago
  That sounds exactly like a scroll area. For example Dear ImGui has scrolling based on a draw list which will be clipped to the current visible area. Nothing stopping adding panning and zoom controls for this. In fact I saw mouse panning added in one of the ImColorTextEdit forks. Maybe Dear Imgui doesn't have a "zoom" feature built-in, but I don't imagine that being hard to implement. Just additional scaling and clipping to the draw list.
  - 0x1ceb00da 2y ago
    Can it be done outside of the library in the user code?
    - dsp_person 2y ago
      Click to drag yes since it's just using ImGui::SetScrollX, ImGui::SetScrollY based on mouse events. For zoom, it could be in user code if it's your own custom widgets or rendering with ImGui::GetWindowDrawList()->Add{Something}, but I don't think Dear ImGui has a super great api for zoom with the built in windows/widgets like we're talking about here. It's a limitation of this api, not the immediate mode paradigm in general (like the article argues). For example, ImColorTextEdit renders an ImGui:Dummy() to create a dummy widget of a specified width and height which defines the scroll area, and then based on the current ImGui::GetScrollX() and ImGui::GetScrollY() it uses ImGui::GetWindowDrawList()->Add{Rectangle,Line,Text, etc} to custom render the contents inside the widget based on what should be visible at the scroll positions. Since it's custom code it would be easy to use a zoom param to adjust the scale of things and what is submitted to the draw list.

58 points by ibobev 2y ago

> The structure and function of your UI is naturally expressed in the code of the functions that draw it, instead of in ephemeral and opaque object trees that only exist in RAM after they're constructed at runtime This is probably it (although perhaps it is not quite the best explanation, but the example in the article helps to explain it); there are many possible implementations of an idea such as this. However, depending on the program and on other stuff, it is not always best for all kind of programs and all kind of UI. (In some cases, a kind of hybrid might do.) And, as they say about the example, there are things to criticize about it. Still, it can show an example of its use, even though it is a simple example. I had made my own variant of IMGUI. It uses a "win_form" block, which can be nested and which supports "break", and various other commands inside of the win_form block such as "win_command", "win_numeric", "win_boolean", etc; these commands do not have to be directly but can also be inside of a "if", "for", "switch", etc. These are implemented by C99 macros. The amount of state is small, not more than twenty bytes per active form (regardless of the number of widgets), and it is stored in the stack (but there is no need to explicitly add commands to declare or allocate this state; the "win_form" macro does this automatically). The git repository https://github.com/zzo38/superzz0 https://github.com/zzo38/superzz0 is for a program that contains this UI implementation. The file called "common.h" contains the macros and function declarations, and "window.c" contains the implementation. You can see many uses of it in "edit.c" (search for "win_form" to find many of the uses). As they say in the article, immediate mode does not necessarily mean that the library doesn't retain data (mine retains a single pointer, which is used to restore state when leaving a nested win_form block), that it needs a GPU to render, etc.

Zecc 2y ago
For some reason your comment shows as having been posted 6 days ago (or 8 days ago when editing my reply) even though this thread was created only 3 hours ago. What is happening here?
- coryrc 2y ago
  Sometimes submissions that don't get traction originally get merged into a more recent one that becomes popular. Though... `past` link doesn't show anything else, but that might be because it was merged?
- zzo38computer 2y ago
  I don't know. I know I wrote it many days ago and not today, but on my computer it says 8 days ago on the /threads list but on this list it says 6 days.

bgribble 2y ago

I love the developer experience of Dear ImGUI, even though I use it through Python wrappers that confuse things sometimes. It just slices like a sword through several layers of often-pointless abstraction and puts the control over the main loop right in your hands. And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.

krapp 2y ago
It should be the go to for general purpose cross-platform application UI development (instead of Electron,) and it's unfortunate that something so good and so useful is only meant for debuggers and editors.
- tom_ 2y ago
  On the flip side, targeting developers tightens the scope quite a lot! If nothing else, it massively increases the chance your target audience can at least get by with left-to-right text and 7-bit ASCII... Cornut recently did a 10 year retrospective of Dear ImGui: https://github.com/ocornut/imgui/issues/7892 https://github.com/ocornut/imgui/issues/7892 - an interesting read for me, as a Dear ImGui library user for many years now, but worth your time I think even if you aren't a user yourself. There is a specific section about the scope of the library: https://github.com/ocornut/imgui/issues/7892#issuecomment-2291436235 https://github.com/ocornut/imgui/issues/7892#issuecomment-22...
- fassssst 2y ago
  Only if you don’t care about accessibility and common controls.
  - krapp 2y ago
    You might have a point about accessibility, but what common controls does Dear IMGui lack? It has just about every control I can think of.
    - 2y ago

amelius 2y ago

Say I have a very long listbox containing thousands of items, and each item has a height that may be different (e.g. a list of font families where each line may have a slightly different line height). How would IMGUI perform the drawing, given the scrollbar is at (say) 20%?

deleted 2y ago
[deleted]
tom_ 2y ago
I'm not sure I've ever used any library that goes to any particular effort to support this sort of thing. The standard assumption for listboxes is that every row has the same height. So you'd probably handle it the same way you would with any other system: accept that there'll be some effort involved, and get the library to do the remainder for you. So, probably, something like let the library know the total height of the contents, have it look after the viewport height and scroll bar position for you, and then draw the viewport contents as required.
- loic-sharma 2y ago
  Your browser goes through extraordinary lengths to support this sort of thing.
  - tom_ 2y ago
    I guess I just got old at some point. I simply don't think of web browsers as relevant when it comes to programming.
troad 2y ago
I feel like I must be missing something here. Why not store the ID of the top-most visible list item, and just render the next n until you run out of box height? Surely you're not trying to draw thousands of items that aren't even visible on screen?
badsectoracula 2y ago

lylejantzi3rd 2y ago

> they are different interpretation of what IMGUI means? Yes. Good luck clearing that up. The programming community as a whole couldn't even get Object Oriented Programming right. It originally meant little machines passing messages to each other (Smalltalk, Objective-C). What we got was inheritance, encapsulation, and polymorphism (Java).

igouy 2y ago
> It originally meant "Smalltalk encourages well-factored designs through inheritance. Every class inherits behavior from its superclass … all forms of ordered collections in the system will instantly acquire this new capability through inheritance." "Modularity: No component in a complex system should depend on the internal details of any other component." "Polymorphism: A program should specify only the behavior of objects, not their representation." 1981 "Design Principles Behind Smalltalk" Daniel H. H. Ingalls https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

ogogmad 2y ago

Are there GUI builders like for VB6, but for IMGUI libraries?

gyomu 2y ago
Posted last week: ImRAD is a GUI builder for the ImGui library https://news.ycombinator.com/item?id=41261426 https://news.ycombinator.com/item?id=41261426

malkia 2y ago

On the other hand, flutter has plenty of state management options :) - https://docs.flutter.dev/data-and-backend/state-mgmt/options https://docs.flutter.dev/data-and-backend/state-mgmt/options - it's like living in the US, you don't like how your state is managed - move to the next one!

jesse__ 2y ago

Somewhat of a nitpick.. > The acronym is misleading because "immediate-mode" was initially coined as a reference to obsolete graphics API which made it very easy to render contents. Is that actually true? From what I remember of hearing Casey (the person who coined the term) talk about it on Handmade Hero and various other streams, it's differentiating between 'immediate mode' and 'retained mode' GUI APIs (QT, GTK, Swing, MFC .. etc) which make you retain handles to UI elements. AFAIK it didn't have anything to do with the graphics API whatsoever ..? Right? EDIT: Watched the video linked of Casey from 05, which I'd never seen before and was quite interesting. I'm not totally convinced that the small portion he talked about renderer APIs near the 10 minute mark substantiates the claim, but it might.

bob1029 2y ago
https://learn.microsoft.com/en-us/windows/win32/learnwin32/retained-mode-versus-immediate-mode https://learn.microsoft.com/en-us/windows/win32/learnwin32/r... I think you could also draw some analogies between server side and client side rendering. Where the authoritative view state lives is the most important bit I think.
phire 2y ago
Yes, it's true. Direct3D had a retained mode up until version 3.0, but the only examples of it ever being used in a commercially successful game was LEGO Island and LEGO Rock Raiders. Instead of supplying all the draw commands every frame, you would give it your 3D scene and it would draw it.
- badsectoracula 2y ago
  I tried to use it (for fun) at some point but the API design felt too verbose/cumbersome for what it did and by the time DrawPrimitive was added in D3D5 it was simpler to use that directly than use D3DRM. It was also very clear that D3DRM was designed by a different team than D3DIM.
- torlok 2y ago
  All modern graphics APIs are retained mode, because you push data to the GPU and the GPU maintains its own state. The closest you can get to immediate mode is OpenGL 1.0 with glBegin, etc.

badsectoracula 2y ago

One of my perverse ideas for a project is to make a Dear ImGUI (the most common IMGUI library and basically what many people associate with "ImGUI") backend for Lazarus/LCL (the most non-IMGUI/Retained mode framework you can probably think with OOP -something that IMGUI aficionados seem to have a distaste for- layers thick enough to act as armor :-P).

akira2501 2y ago

> "Minimize state synchronization." > void UpdateUI() Minimize state synchronization by effectively synchronizing state on each screen refresh? > "Minimize state storage on user side." > Immediate mode is a style of API where important state is kept in user code Then reduce state stored in user code by storing "important state" in user code? > "Minimize setup and maintenance." I don't find the example convincing. It seems like any more complexity beyond this toy example puts you right back where you started. Building components by hand is stone age ideology regardless of how you push state. https://github.com/ocornut/imgui/blob/master/examples/example_allegro5/main.cpp https://github.com/ocornut/imgui/blob/master/examples/exampl... > "Easy to use to create dynamic UI which are the reflection of a dynamic data set." Which is great for a video game.

tom_ 2y ago
Try it! Worst thing that'll happen is that you'll still hate it.

d--b 2y ago

> Nowadays I am starting to believe that the term has caused more harm than benefits, because it suggests there are two camps "IMGUI" vs "RMGUI". The reality is there is a continuum of possibilities over multiple unrelated axises. > The fact that we are even trying to put an official definition to a label is hindering people's imagination about the many possible areas of researches to be done in UI space. Well said, but then the author proceeds and lists what IMGUI is and what it’s not. My opinion is that we may just think about IMGUI as “the stuff that dear-imgui does”, which people understand well. And yes there’s a loop, and things get redrawn all the time and so on. Everything else that borrows concepts from that is IMGUI-ish. I for myself definitely use some IMGUI concept when I do js apps, but is it imgui? Definitely not. Is it imgui-ish, hell yeah. Trying to make the term IMGUI mean “good way of doing UI” is not gonna work…

torlok 2y ago
It sucks that this is what immediate mode got reduced to. If you listen to what Casey was advocating for, it was to avoid the need to synchronise state between local state and black box state. This can be applied to UI, but just as well to f.e. a physics engine, where a constraint can live as long as you keep calling doConstraint(). Unfortunately, all people seem to have gotten out of that was if(doButton(...)).
theamk 2y ago
There maybe a continium in games space, but in non-game apps it's all crystal clear and sharp boundaries: Can the app stop generating wakeup interrupts and let CPU/GPU sleep? Yes -> this means app events (like network transfer) need to be able to generate "update" events, which means those events need to be directed somewhere, which means retained mode. No -> this means GUI is allowed to poll non-stop and thus can check every variable 60 times per second to support immediate mode.
- modeless 2y ago
  Immediate mode and polling are not the same thing. With Dear ImGui you own the event loop so you can draw as frequently or infrequently as you want. It is not necessary to draw 60 times per second when nothing is happening. Dear ImGui's sample code currently does draw every frame even when nothing is happening. Omar has said that he would eventually like to change this and it's on his roadmap, but it's low priority because he is currently targeting game industry users and doesn't want to attract a lot more users in other areas that will add to his support load and dilute his focus. [1] He also has said the same thing about accessibility and fancy theming. These features are good examples of why "the stuff that dear-imgui does" is not a good definition of immediate mode. People often assume that anything Dear Imgui doesn't do is hard or impossible for any immediate mode API, but that's far from the truth. Omar is only one guy. He has a target audience in mind and is not trying to satisfy all use cases at once. You have to remember that when comparing Dear ImGui to a framework like Qt or SwiftUI or whatever that has hundreds if not thousands of developers contributing to it. [1] https://github.com/ocornut/imgui/issues/7892 https://github.com/ocornut/imgui/issues/7892

dsp_person 2y ago

> IMGUI does not mean it needs to refresh all-or-nothing. The author of microui described an interesting approach to this here https://rxi.github.io/cached_software_rendering.html https://rxi.github.io/cached_software_rendering.html

pjmlp 2y ago

Basically, it is how we did graphics programming back in MS-DOS, UNIX framebuffers, and everywhere else where desktop OSes didn't had a GUI framework to start with.

sweeter 2y ago

I hate writing GUI's, I cannot get them to "click" with me, but for some reason the immediate mode GUI paradigm makes a lot more sense to me. It doesn't help that UI code is usually really blocky and error prone either, but IMGUI and GIO are great

giovannibonetti 2y ago
Working with GUIs really "clicked" with me when I learned the Elm programming language and framework for building web applications (front-end) [1]. The Model-View-Update paradigm matches very well the UML state machine modelling taught in universities [2]. [1] https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/ [2] https://en.wikipedia.org/wiki/UML_state_machine https://en.wikipedia.org/wiki/UML_state_machine

0x1ceb00da 2y ago

One thing I never figured out how to do in an immediate mode system is encapsulating functionality. In a retained mode system I can have, for example, a panning view widget, which wraps another widget and allows you to pan and zoom using the mouse. How would one encapsulate such functionality with an immediate mode ui toolkit?

dsp_person 2y ago
That sounds exactly like a scroll area. For example Dear ImGui has scrolling based on a draw list which will be clipped to the current visible area. Nothing stopping adding panning and zoom controls for this. In fact I saw mouse panning added in one of the ImColorTextEdit forks. Maybe Dear Imgui doesn't have a "zoom" feature built-in, but I don't imagine that being hard to implement. Just additional scaling and clipping to the draw list.
- 0x1ceb00da 2y ago
  Can it be done outside of the library in the user code?
  - dsp_person 2y ago
    Click to drag yes since it's just using ImGui::SetScrollX, ImGui::SetScrollY based on mouse events. For zoom, it could be in user code if it's your own custom widgets or rendering with ImGui::GetWindowDrawList()->Add{Something}, but I don't think Dear ImGui has a super great api for zoom with the built in windows/widgets like we're talking about here. It's a limitation of this api, not the immediate mode paradigm in general (like the article argues). For example, ImColorTextEdit renders an ImGui:Dummy() to create a dummy widget of a specified width and height which defines the scroll area, and then based on the current ImGui::GetScrollX() and ImGui::GetScrollY() it uses ImGui::GetWindowDrawList()->Add{Rectangle,Line,Text, etc} to custom render the contents inside the widget based on what should be visible at the scroll positions. Since it's custom code it would be easy to use a zoom param to adjust the scale of things and what is submitted to the draw list.