[HN Gopher] Immediate Mode GUI Programming
       ___________________________________________________________________
        
       Immediate Mode GUI Programming
        
       Author : jstanley
       Score  : 14 points
       Date   : 2024-01-15 21:33 UTC (1 hours ago)
        
 (HTM) web link (eliasnaur.com)
 (TXT) w3m dump (eliasnaur.com)
        
       | moron4hire wrote:
       | Immediate mode GUI is fine for quick and dirty things, but once
       | you start dealing with multiple application views that
       | conditionally show/hide, with branching flows of any kind, you'll
       | find yourself on a hardline track to reinvent retained mode GUI
       | from scratch just so you can handle the event loop in a sane way.
       | 
       | Object oriented, event driven widgets composed into more colored
       | views are really, really good for developing UI. There's a reason
       | every major OS GUI toolkit is this design. If you componentize
       | like you are supposed to--instead of just smashing everything
       | into one form--they work and can be reasoned over with few
       | surprises.
       | 
       | The trouble comes from not componentizing things that you should
       | when your current platform doesn't provide the full menagerie of
       | widgets that you'll need. Basically, it you have any kind of
       | input that results in a value that is not just a raw string, you
       | should be building a component for that input: URLs, paths to
       | files, numbers, dates, selectors for picking a set list of
       | structured objects, etc.
        
         | flohofwoe wrote:
         | Isn't the whole point of immediate mode UIs to get rid of the
         | "event loop" though?
         | 
         | > multiple application views that conditionally show/hide
         | 
         | The ImGui way of doing this is to conditionally run or not run
         | the code which describes the conditionally shown UI elements.
         | E.g. a simple                   if (viewShown) {
         | ...code which describes what the view looks like         }
         | 
         | There are plenty of real-world applications with complex UIs
         | implemented in Dear ImGui which don't seem to have a problem
         | with those things, e.g. see
         | https://github.com/ocornut/imgui/labels/gallery
         | 
         | > The trouble comes from not componentizing things...
         | 
         | In ImGui, reusable UI components are just code which describes
         | the UI component by calling lower-level ImGui functions and
         | which itself is a new ImGui-style function. It works
         | surprisingly well.
        
           | moron4hire wrote:
           | [delayed]
        
       | flohofwoe wrote:
       | TBH from looking at the code examples it looks a bit like it's
       | halfway stuck between a traditional object-oriented UI framework,
       | and a "proper" immediate mode UI (for instance why is there a
       | variable that seems to be a button object).
        
       | jbverschoor wrote:
       | Immediate mode is very common in game development. Super easy to
       | reason about and debug.
        
       | treyd wrote:
       | Kinda an unfortunate name collision with GIO as used in another
       | UI toolkit stack: https://en.wikipedia.org/wiki/GIO_(software)
        
       ___________________________________________________________________
       (page generated 2024-01-15 23:00 UTC)