[HN Gopher] Dear ImGui: Graphical User Interface library for C++
___________________________________________________________________
Dear ImGui: Graphical User Interface library for C++
Author : _benj
Score : 113 points
Date : 2023-12-20 17:01 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ImPleadThe5th wrote:
| Does anyone know what the name is a reference to?
| _benj wrote:
| Idk about "dear" but ImGUI I believe stand for "immediate mode
| graphical user interface"
| laserbeam wrote:
| From the faq
| https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-w...
|
| Q. What is this library called?
|
| This library is called Dear ImGui. Please refer to it as Dear
| ImGui (not ImGui, not IMGUI).
|
| (The library misleadingly started its life in 2014 as "ImGui"
| due to the fact that I didn't give it a proper name when I
| released 1.0, and had no particular expectation that it would
| take off. However, the term IMGUI (immediate-mode graphical
| user interface) was coined before and is being used in variety
| of other situations e.g. Unity uses it own implementation of
| the IMGUI paradigm. To reduce the ambiguity without affecting
| existing code bases, I have decided in December 2015 a fully
| qualified name "Dear ImGui" for this library.
| 1propionyl wrote:
| My first guess would be it is supposed to sound like "Dear
| Imogen". However, it wasn't initially conceived of as a
| reference to anything. The "Dear" was tacked on to qualify the
| name [1].
|
| [1]
| https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-w...
| ImPleadThe5th wrote:
| Just seems like a weird way to qualify the name is all.
| cristeigabriel wrote:
| I think it fits, Dear ImGui is the most popular immediate
| mode GUI, and it's what most people think of when they hear
| "imgui" even though I've seen people shorten "immediate
| mode GUI" to "imgui" too.
| Der_Einzige wrote:
| The related DearPyGUI is so cool.
| https://github.com/hoffstadt/DearPyGui
| bgribble wrote:
| I have been a fairly devoted user of Gtk in my Python programs
| for about 20 years. Back then, it was a clean, simple,
| functional toolkit that just worked.
|
| Dear ImGUI cleans Gtk's clock in the "clean", "simple",
| "functional", and "just works" categories these days, and I am
| currently porting my biggest side project from Gtk to Imgui.
|
| If you are trying to "integrate with the (GNOME) desktop", I'm
| sure you should still use Gtk, but for most purposes I don't
| see the point. It seems from the outside like there are few
| core Gtk developers left, and they are basically in life
| support mode for an entire desktop suite, one that is stuck
| between two broken display engines (Xorg and Wayland) with no
| way to really fix things and every desktop Linux user expecting
| miracles.
|
| ImGUI is just a busy dude banging away on a single toolkit,
| without the baggage of millions of nontechnical users to
| support. As a developer, I know which one is going to be
| producing the good stuff.
| 127361 wrote:
| Beautiful interface design there, and it's fully customizable to
| your liking as well. It also supports keyboard shortcuts.
| OskarS wrote:
| You really think so? This is really my biggest issue with Dear
| ImGui, I think it just looks awful. The design is just not
| great, and stuff like text rendering has been terrible in every
| Dear ImGui UI I've seen. Especially on macOS, the native
| applications there really make ImGui stuff look pretty crappy.
| Electron apps also generally speaking just look way better,
| IMHO (Electron has other issues obviously, but the ones I use
| regularly look pretty good). Like, imagine VSCode or something
| with the graphical style of the screenshots on the GitHub page.
|
| Maybe you can customize it and make it look great, but the "out
| of the box" experience is just... oof.
| 127361 wrote:
| Yes, you can customize it, both the color scheme and the
| element spacing. And the font scaling (the internal
| resolution in the texture) can be fixed to make the fonts
| look nicer. Someone made a subpixel font rendering patch for
| ImGUI as well.
| cristeigabriel wrote:
| ImGui supports multiple text rasterizers.
| HelloNurse wrote:
| Normally, in a game there is a completely separate not-awful-
| looking GUI system for the player, pushing Dear ImGui towards
| the opposite niches: simple in order to be easy and efficient
| to write rather than complex in order to be general and
| flexible, evolution through changing (mostly adding) widgets
| and assimilating more data rather than through improved
| appearance and behaviour of a relatively simple and stable
| GUI, "just working" and low churn rather than configurable,
| cheap rather than accessible, and so on.
| bArray wrote:
| I've used Dear PyGui [1], which is based on this, and it has been
| a mixed bag. It's fast and basic functionality is super simple.
| The documentation is somewhat lacking when you wanted to start
| doing something non-standard. I would still rate it quite highly
| all things considered.
|
| [1] https://github.com/hoffstadt/DearPyGui
| tomovo wrote:
| Spotting it in various videos of scientific, game development &
| graphics tools is a bit like hearing the Wilhelm scream in
| movies.
| TillE wrote:
| Yeah it's a heartwarming open source success story in game
| development. _Everybody_ uses it for internal tools (just check
| their sponsors list to start with), and it occasionally shows
| up as like a debug menu in production code.
| tverbeure wrote:
| I've dabbled with Qt and other heavy GUI tools before.
| Switching to Imgui was a breath of fresh air.
|
| And I love how it allows me develop for Windows, Linux and
| MacOs with minimal overhead.
| flohofwoe wrote:
| I just used Dear ImGui in a VSCode tab in the last couple of
| weeks [1] :)
|
| ...indirectly by embedding a home computer emulator with a Dear
| ImGui debugger UI, compiled to WASM+WebGL running in a webview
| panel, but the idea to use Dear ImGui for tooling UIs in VSCode
| extensions where HTML+CSS might be too awkward is certainly
| interesting (think not just "traditional UIs", but also things
| like noodle-graphs, flame-graphs, diagrams... the vector renderer
| coming with Dear ImGui is great for that type of stuff).
|
| [1]
| https://marketplace.visualstudio.com/items?itemName=floooh.v...
| mortallywounded wrote:
| > ..by embedding a home computer emulator with a Dear ImGui
| debugger UI, compiled to WASM+WebGL running in a webview
| panel...
|
| People wonder why their Electron apps use 16GB of memory.
| flohofwoe wrote:
| ...and yet there's no realistic way to implement such an
| extension for any other IDE without resorting to per-
| platform-compiled and potentially unsafe native code :)
|
| The embedded emulator including the Dear ImGui debugging UI
| compiled to WASM is just around 700 KBytes, runs on all
| platforms (even in the VSCode browser version) and is safely
| sandboxed, that same code compiled to a native executable on
| macOS is 847 KBytes, doesn't run on any other OS without
| compiling another version, and would be blocked to run anyway
| because it is potentially unsafe.
| WhereIsTheTruth wrote:
| Turns out VScode is indeed a web browser in disguise, who
| would have thought!
| slalomskiing wrote:
| I've worked with a lot of different UI frameworks (both native
| and web) and ImGui is definitely my favourite
|
| It's just so simple
|
| For example adding an input box for editing a float value is one
| line of code and the syncing is done by just passing it a
| pointer.
| nox100 wrote:
| Dear ImGUI is amazing and I wish all UI development was so easy
| and simple.
|
| That said, be aware its original purpose is as a UI for internal
| game dev tools and not customer facing tool. It's neither
| international friendly nor accessibility friendly. Those are 2
| feature usually not needed for internal tools.
| jakelazaroff wrote:
| A word of caution that Dear ImGui is specifically made for
| building internal tools quickly rather than production-grade UIs.
| Relevant quote from the docs:
|
| _> Dear ImGui is designed to enable fast iterations and to
| empower programmers to create content creation tools and
| visualization / debug tools (as opposed to UI for the average
| end-user). It favors simplicity and productivity toward this goal
| and lacks certain features commonly found in more high-level
| libraries._
|
| Here's a quote from my comment [1] on an earlier discussion about
| Dear ImGui vs. "bloated" browser APIs:
|
| _> This is what I hear when I enable VoiceOver on macOS and open
| Discord (either the web app or the desktop app):_
|
| _> 1. "Discord, friends - Discord window, direct messages,
| selected cell"_
|
| _> 2. "You are currently on a cell inside of a table. To
| navigate the cells within a table, press..."_
|
| _> 3. (when navigating with the keyboard) "1 mention,
| $SERVER_NAME, cell" "$SERVER_NAME, cell" etc_
|
| _> And here's when I do the same with a random Dear ImGui app I
| have installed:_
|
| _> 1. "$APP_NAME, $APP_NAME window, $APP_NAME window"_
|
| _> 2. "You are currently in a window"_
|
| _> 3. (when navigating with the keyboard) [silence; no
| additional instructions]_
|
| [1] https://news.ycombinator.com/item?id=37302809
| Conscat wrote:
| Yet people do indeed make professional software with it, such
| as RemedyBG.
| mananaysiempre wrote:
| Is RemedyBG actually accessible to blind users though?
| mwcampbell wrote:
| No. Just bought it so I could check. Edit: I'd be happy to
| spend some time helping the developer with this if they're
| interested.
| jakelazaroff wrote:
| Sure, if you put in a lot of effort you could probably make a
| professional app with it. You'd need to recreate a bunch of
| features that come for free in more "bloated" UI libraries.
| But you could do it! More likely, though, is that you won't
| and your "professional" app will just end up being bad for
| lack of those features.
| cxr wrote:
| This comment-and-response pair has a really weird "shape".
|
| You're offering a retort to someone who is communicating
| their position that you ought not do something, where the
| retort consists of nothing more than explaining that people
| are doing it. Yes, clearly. But what the person you're
| responding to is arguing is that _you ought not do it_.
|
| Consider the following hypothetical:
|
| Person A: _Here 's little advice: don't take up smoking.
| Smoking is bad for you._
|
| Person B: _Yet people smoke--my cousin, for example._
|
| The point of the other comment wasn't that it isn't happening
| or that it's physically impossible to even try. Indeed, the
| fact that it's being done--or that people are attracted, at
| least, to trying to do it--was rather the entire premise of
| their "word of caution".
| stagger87 wrote:
| I see a different "shape". To me it looks like the same
| accessibility song and dance that happens every time a GUI
| library is the topic.
| mort96 wrote:
| Is accessibility not a worthwhile concern?
| stagger87 wrote:
| What answer are you expecting? This question is
| borderline flame bait.
| mort96 wrote:
| It seemed like you were criticizing the "accessibility
| song and dance that happens every time a GUI library is
| the topic", as if you think accessibility concerns are
| over-blown. If that wasn't your intention, I suggest you
| clarify what you actually mean.
| tom_ wrote:
| It seems this might not be the case for American English,
| but "song and dance" is only ever dismissive in British
| English. The implication is that the complaints are a
| needless distraction, due to the relative insignificance
| of the topic.
| jakelazaroff wrote:
| Yes, that's the case for American English too.
| phkahler wrote:
| Probably not for internal custom tools.
| mort96 wrote:
| I agree, which ... is why jakelazaroff is warning that
| ImGui is meant for internal custom tools, not tools where
| things like accessibility is a concern.
| djur wrote:
| Accessibility is only not a concern for internal custom
| tools if you're certain you're not going to hire anybody
| with a disability that requires those accessibility
| features. (You shouldn't be certain of this, because it
| means you're probably breaking the law.)
| mort96 wrote:
| This is kind of a kinda ridiculous argument. You're not
| gonna hire a blind level designer or blind character
| artist.
| jakelazaroff wrote:
| Accessibility is one (important) consideration but it's
| true that tools with a small, known subset of users can
| afford to ignore some constraints. For example, if you're
| a small American company, your internal tools might not
| need to support right-to-left languages.
| radiator wrote:
| This is for the creators to decide. Nobody else has a
| say, really.
| mort96 wrote:
| Accepting this, for the sake of argument: sounds like
| warnings such as jakelazaroff's are a good thing then, to
| make sure creators are informed enough to decide.
| panzi wrote:
| Except the law in Europe.
| bigstrat2003 wrote:
| I wouldn't go that far. But "this lacks accessibility"
| isn't sufficient reason to rule something out, imo. It's
| better for a piece of software to exist, without
| accessibility accommodations, than it is for it to not
| exist at all.
| djur wrote:
| No, there's a tradeoff. If non-accessible software
| outcompetes and crowds out accessible software, that
| degrades the ability of people who need accessible
| software to use their computers. It is entirely
| reasonable for people who think that people with
| disabilities should have equal access to technology to
| advocate against the development of software without
| accessibility features.
| panzi wrote:
| Well, here in Europe you can get sued if you provide a
| non-accessible software. (Games are excluded and a photo
| editor can of course assume that the user can see etc.)
| jakelazaroff wrote:
| If the topic is a tool that's missing an important
| feature, then of course people will discuss why that
| tradeoff has been made.
| echelon wrote:
| Ship or don't. If the calculus boils down to this, then
| making suboptimal choices isn't necessary wrong.
| thezilch wrote:
| Why should internal tools not have these things? That kind of
| argument smells of, internal tools can be slow. No.
|
| Seems we should lift up Dear ImGui -- contribute, donate,
| feedback (document, gather requirements, etc), etc -- as
| opposed to suggest we not use it.
| F3nd0 wrote:
| I don't think they shouldn't on principle, but they might not
| need to have them. For example, if there's a limited number
| of people who are going to work with the tools, and you know
| that none of them need such features, it could be entirely
| reasonable not to worry about them.
| djur wrote:
| That's making a bet that you'll have absolutely no need to
| hire someone for that team nor that any of the existing
| members of the team will develop the need for accessibility
| features.
| ocornut wrote:
| Dear ImGui is lacking good and focused code contributors, I'm
| stretching myself quite thin already and unfortunately
| pragmatically it currently wouldn't be wise for me to attempt
| working on accessibility features :( Right now the state of
| things is that a majority of even the simplest PR are poor
| quality, so I'm not too hopeful that such a complex feature
| would magically start getting good contributions. I am
| personally just accepting that things are going to take years
| to move forward. I'd rather have them more slow and stay
| sane. Dear ImGui is intentionally gated and made fugly for
| those reasons as well.
|
| But any effort to document, specs, clarify etc would be
| helpful and not just to Dear ImGui.
|
| Accessibility is a whole world that is hard to grasp when you
| are not a end-user, API are large, confusing, poorly
| documented, and I presume that there are a large variety of
| tools and use cases and it's even hard to gauge what are the
| low-hanging fruits that would be the best to implement/bind.
|
| Given how obfuscated Web stacks are nowadays (since they do
| try to prevent unauthorized scrapping and automation), I'm
| honestly also a little bit surprised that nowadays screen
| readers aren't relying on OCR more?
| malkia wrote:
| Supporting screen readers - e.g. accessibility, apart from the
| obvious benefit to the users, gives you almost for free
| testing/automation abilities too
| ocornut wrote:
| Good Testing/Automation is never free lunch AFAIK but Dear
| ImGui has a testing/automation system:
| https://github.com/ocornut/imgui_test_engine
| topspin wrote:
| Tools that are popular with developers tend to evolve into
| tools that end up in use by everyone.
|
| Your caution isn't wrong, but ultimately it may be futile.
| jakelazaroff wrote:
| Ultimately, I only really care about the outcomes. If people
| want to use Dear ImGui for their production apps _and_ put in
| the work to make it, well, production-ready, I 'm totally
| fine with that.
| devmor wrote:
| My introduction to this UI was actually from a (unapproved) 3rd
| party modding framework developed for the MMORPG Final Fantasy
| 14.
|
| The tool creators needed some way to provide mod developers with
| access to a unified UI, and hooking the game's built-in UI was
| far too high effort for the reward.
|
| I played around with it to develop a couple mods for fun and have
| since become a huge fan of it, and started using Dear ImGUI to
| add interfaces to some of my personal tools that were previously
| CLI-only.
| Ralo wrote:
| Looking at the leaked GTA VI videos and seeing ImGui being used
| by Rockstar internally is pretty neat how even a multi-billion
| dollar studio will use the same open source project we all use.
| danhau wrote:
| Reminds me of that ,,A PROJECT SOME RANDOM PERSON IN NEBRASKA
| HAS BEEN THANKLESSLY MAINTAINING SINCE 2003 image."
|
| Sorry for caps (transcribed from image).
| KomoD wrote:
| https://xkcd.com/2347/
| shrubble wrote:
| Alternatively, the "runk" tool https://www.reddit.com/r/Progr
| ammerHumor/comments/umg9ps/run...
| notpushkin wrote:
| > Sorry for the caps
|
| You can use tr to quickly convert it to lowercase:
| pbpaste | tr '[:upper:]' '[:lower:]'
|
| (Though I usually paste text in VSCodium and convert it
| there.)
| zengid wrote:
| I'd like to see a middle ground between immediate mode and
| retained mode, where the UI is more like a scene-graph where you
| have nodes with transforms, but you can draw anything inside
| them, and the framework will keep track of all the matrix math
| for you like a game engine would. Maybe no one would find that
| useful, but its something I'd like to tinker with.
| kevingadd wrote:
| My personal IMGUI library [1] is what I call "partially
| retained" in that there is an immediate mode API similar to
| dear imgui or nuklear on top, but under the hood the immediate
| mode API just manages retained mode object graphs for you
| automatically.
|
| This is a fantastic (imo) way to build user interfaces, because
| sometimes the most convenient way to manage state or construct
| a complex widget is to write a retained mode object that hosts
| some other child objects, and in other circumstances it's most
| convenient to write a modal dialog or something by just
| slamming out some imgui code in a standalone function.
|
| I also think the imgui approach to layout (use an algorithm
| that can fully reconstruct your layout from scratch every frame
| without much of a performance penalty) removes a lot of
| potential bugs and quirks that are common in UI, like one-frame
| glitches or having to manually propagate state through a bunch
| of objects and layers. Though imgui approaches have their own
| downsides, like the "page tearing" issue. I've had to do some
| weird contortions to solve that one in my own code and I still
| get bugs occasionally.
|
| The game I'm building right now does almost all of its scene
| layout and UI as a single graph of components that mix retained
| and immediate mode, and it's been a relaxing way to do things
| compared to the 'manually paint widgets in places and do hit
| testing' approach I've used for some previous titles.
|
| A large portion of the UI is constructed via what I'd call
| 'value replication', where a container control is attached to a
| list of game objects (entities, components attached to
| entities, parameters to a script) and then the container
| automatically creates a list of child controls for each game
| object automatically. This allows easy virtualization (i.e.
| only having 20 controls to represent a scrolling view with 1000
| items) and means I don't have to manually do a bunch of state
| synchronization.
|
| 1: https://github.com/sq/Libraries/tree/master/Squared/PRGUI
| zengid wrote:
| Super cool, thank you for sharing!!
| cedws wrote:
| ImGui is brilliant. I can highly recommend this hex editor built
| using it: https://github.com/WerWolv/ImHex
| lxe wrote:
| Is there a non-webgpu wasm/emscripten demo somewhere? I remember
| seeing a ton of them earlier. Or maybe I'm thinking of the rust
| version:
|
| https://github.com/emilk/egui
| joeld42 wrote:
| There's a bunch here
|
| https://github.com/floooh/sokol-samples
|
| For example, the basic demo window:
|
| https://floooh.github.io/sokol-html5/imgui-sapp.html
| ocornut wrote:
| Also see the interactive web manual
| https://pthom.github.io/imgui_manual_online/manual/imgui_man...
| kelvie wrote:
| I've also played around with the Rust version egui, and with the
| eframe template it's super easy to bang out super quick GUI tools
| on github pages (for example, I made a basic guitar fretboard
| chord finder [1] to help me learn guitar in a few hours, plus a
| few more hours refining it)
|
| The mental model of immediate mode guis makes it really easy to
| work on it as a side project with 10-20 minutes here or there
| before bed, though doing proper layout to make it look nice is
| sometimes a challenge. The other advantage is that I can just
| jump into the implementation, and the egui code itself is pretty
| easy to grok.
|
| [1] https://kelvie.github.io/chord-finder
| kelvie wrote:
| One thing I will add is that this paradigm really encourages
| either making a ton of functions (which IMO makes code flow
| harder to read for these kinds of low-effort projects), or
| having a lot of scoped statements.
|
| A good addition would be something like how flutter's LSP-based
| tools, which I use in Emacs), have a "wrap with widget" auto-
| refactoring tool, for e.g. when you want to wrap an entire
| widget tree in a new layout without having to do it manually.
| cristeigabriel wrote:
| Egui is not the "Rust version" of ImGui. There's libraries
| which allow for ImGui in other languages by applying the
| hourglass pattern first (making a C api for the C++ api), to
| allow for the creation of bindings, since most languages
| support C FFI, and then somebody writes an API in the target
| language which calls to (and maybe extends) the C api.
| dazzawazza wrote:
| I've written video game editors in Win32, MFC, wxWidgets, Fox
| Toolkit, Qt, Cocoa and Dear ImGUI.
|
| I will never use anything other than Dear ImGUI from now on. The
| explicitness, lack of state, speed of development and
| maintainability of the code means it wins hands down.
|
| Well worth investing your time in and if you are a leader in the
| games industry well worth supporting financially.
| cristeigabriel wrote:
| I believe you mean the (general) transparency of state? But
| yes, that's quite great when you're getting stuff together
| quickly. It's even used for more serious stuff, where immediate
| mode is a necessity.
| mort96 wrote:
| The "lack of state" refers to being immediate mode rather
| than retained mode.
| cristeigabriel wrote:
| It does require some state in the back for everything to
| work as it does.
| mort96 wrote:
| Of course. The API is stateless but the implementation
| isn't. That's usually how good immediate mode APIs work.
| synergy20 wrote:
| why not use game engine(godot,etc) directly and write your
| editor on top of that instead?
|
| ImGUI is cool for gaming yes, but not good for daily normal GUI
| desktop apps, per the design.
| elpocko wrote:
| It is nice for a developer, but I don't like it as a user. It
| doesn't look or feel good or right, nothing works like you're
| used to, keyboard support is clunky. I like it as cool a dev
| tool but I don't want to do real work using that UI.
| oddthink wrote:
| Is the selling point for this easier custom widgets than in other
| frameworks?
|
| Maybe my standards are too low, but for quick internal tools,
| it's hard to beat 30-year-old Tcl+Tk.
| slabity wrote:
| The selling point is described quite well under "The Pitch"
| section of the README.
|
| Unlike most other toolkits, this one doesn't actually handle
| its own rendering/contexts. It outputs the low-level vertex
| buffers and textures that you can pull into your own graphics
| pipeline. Which means you can integrate it into any sort of 3d
| application or backend that you want.
| soulbadguy wrote:
| Naive question from someone who hasn't touched GUI programming
| since visual studio/QT GUI designer circa 2005 :
|
| Isn't a more declarative approached like XAML/QML (or even
| html/ccs) a better way to represent a GUI interface as opposed to
| an imperative list of command embedded inside the business logic
| of the application ?
|
| How does IMGUI handle theming, reflow or even GPU acceleration on
| different platform ? It seems to me that a more declarive
| representation would allow for better tooling and easier split
| between presentation and themes to match the native platform.
| flohofwoe wrote:
| Dear ImGui code actually looks quite declarative, except that
| the actions are directly 'inlined' into the UI declaration as
| code.
|
| For instance: if (ImGui::Button("Click Me"))
| { // do the stuff that should happen when the
| button is clicked }
|
| To hide a part of the UI you simply skip the code which
| describes that part of the UI. if
| (!btnHidden) { if (ImGui::Button("Click Me")) {
| ... } }
|
| Your code describes what the UI should look like in the current
| frame, and what should happen on user interactions, but without
| event listeners or callback functions.
|
| How you keep the UI declaration separate from the "business
| logic" is up to you. Dear ImGui allows very close coupling
| (which quite often is actually an advantage for adhoc UIs), or
| you can keep both separated as much as you prefer.
|
| > How does IMGUI handle theming, reflow or even GPU
| acceleration on different platform ?
|
| Dear ImGui actually builds an internal "stateful"
| representation of the UI declaration (it needs to remember at
| least some state between frames, otherwise simple features like
| moveable/sizeable windows wouldn't be possible) and then
| generates an optimized list of rendering commands that plug
| almost directly into 3D rendering APIs like D3D, Metal, GL
| etc... (the renderer is implemented outside of Dear ImGui by
| yourself, however Dear ImGui also comes with pluggable example
| renderers and window system glue for pretty much any platform
| and 3D API).
|
| Themeing/skinning is indeed a weak point of Dear ImGui
| specifically, other immediate mode UI frameworks like Nuklear
| offer more flexibility there, but this has nothing to do with
| the imgui philosophy, only with feature sets of specific imgui
| libraries.
| msk-lywenn wrote:
| Are you asking about the IMGUI paradigm or DearIMGUI the
| library? In the case of DearIMGUI: - it does not handle theming
| (but forks do) - I don't know what reflow is - in a way, GPU
| acceleration is the default. In fact, DearIMGUI doesn't handle
| anything at all in that regards because it doesn't have to. You
| are the one responsible for drawing, DearIMGUI just outputs you
| a vertex buffer that you send to the GPU the way you want to.
| There are proposed backends but you can totally roll your own.
| People even have made networked and web backends. I don't know
| how those work.
| WhereIsTheTruth wrote:
| ImGui is engine/GPU agnostic
|
| Themeing isn't a just a retained mode thing, you can do wonders
| with immediate UIs, even though (dear)ImGui doesn't provide
| much, you can still do wonders:
| https://github.com/ocornut/imgui/issues/707#issuecomment-362...
|
| The gaming cheating community is quite creative as well:
| https://www.unknowncheats.me/forum/c-and-c-/505940-advanced-...
|
| More on that topic: https://www.youtube.com/watch?v=Z1qyvQsjK5Y
| Thaxll wrote:
| I worked at multiple major video games studio and they all used
| ImGui internally, most of the time it was for debug in-game ui.
| jckl wrote:
| In school, another student and I used ImGui for a music sampler.
| In retrospect it could have a more friendly interface heh.
|
| https://github.com/EmissionControl2/EmissionControl2
| rollcat wrote:
| Arguably music/"creativity" apps is exactly where immediate
| mode GUIs shine the most. Predictable latency, instant
| feedback, ease of mapping the state to a visual representation,
| reliability and robustness. I can't think of a better match.
| rossant wrote:
| An incredibly powerful GUI library. Not easy to use, only for
| experienced developers. It's quite useful for scientific
| visualization as well! Many kudos to the main developer and the
| community.
| flohofwoe wrote:
| > Not easy to use, only for experienced developers.
|
| Personally I found it a lot easier to grok than (for example)
| React or Qt (as two examples from opposite ends of the
| spectrum).
| dang wrote:
| Related. Others?
|
| _Visual Node Graph with ImGui_ -
| https://news.ycombinator.com/item?id=37702059 - Sept 2023 (90
| comments)
|
| _ImPlot: Interactive plotting library, ImGui style_ -
| https://news.ycombinator.com/item?id=37000594 - Aug 2023 (39
| comments)
|
| _ImGUI Ported to a LiteX SoC_ -
| https://news.ycombinator.com/item?id=34540206 - Jan 2023 (12
| comments)
|
| _Show HN: ImThemes - a Dear ImGui theme browser and editor_ -
| https://news.ycombinator.com/item?id=32290700 - July 2022 (1
| comment)
|
| _Show HN: Python Live GUI - A Hybrid of Dear ImGUI and Phoenix
| LiveView_ - https://news.ycombinator.com/item?id=31679945 - June
| 2022 (19 comments)
|
| _Dear ImGui - Bloat-free graphical user interface library for
| C++_ - https://news.ycombinator.com/item?id=24986908 - Nov 2020
| (180 comments)
|
| _ImPlot: Advanced 2D Plotting for Dear ImGui_ -
| https://news.ycombinator.com/item?id=23128262 - May 2020 (6
| comments)
|
| _Dear ImGui: Bloat-free Immediate Mode GUI for C++ with minimal
| dependencies_ - https://news.ycombinator.com/item?id=23065472 -
| May 2020 (1 comment)
|
| _Runtime Compiled C++ Dear ImGui and DirectX11 Tutorial_ -
| https://news.ycombinator.com/item?id=22233109 - Feb 2020 (12
| comments)
|
| _Could ImGUI Be the Future of GUIs?_ -
| https://news.ycombinator.com/item?id=19745809 - April 2019 (124
| comments)
|
| _Immediate Mode GUI_ -
| https://news.ycombinator.com/item?id=19744513 - April 2019 (128
| comments)
|
| _ImGui: Bloat-Free Immediate Mode GUI for C++ with Minimal
| Dependencies_ - https://news.ycombinator.com/item?id=18121600 -
| Oct 2018 (1 comment)
|
| _ImGui: Bloat-Free Immediate Mode Graphical UI for C++ with
| Minimal Dependencies_ -
| https://news.ycombinator.com/item?id=16193560 - Jan 2018 (1
| comment)
|
| _Using ImGui with modern C++ and STL for creating game dev tools
| - Part 2_ - https://news.ycombinator.com/item?id=12148661 - July
| 2016 (33 comments)
|
| _Imgui: Immediate Mode Graphical User Interface with minimal
| dependencies_ - https://news.ycombinator.com/item?id=8161601 -
| Aug 2014 (41 comments)
|
| _Sol on Immediate Mode GUIs (IMGUI)_ -
| https://news.ycombinator.com/item?id=4201748 - July 2012 (15
| comments)
___________________________________________________________________
(page generated 2023-12-20 23:01 UTC)