I think you forget the fact that his son has 0 ability for self-preservance. In some cases, we may make things that have no chance to exist on their own, persist, but in this case, what does it serve, but our own selfishness?
Seconded. For reference, I have experience with this kind of scenario first hand (helping care, and living with, somebody with dementia combined with complete immobility and many other things making the quality of life for absolutely everybody involved worse). I hope that with time we become more comfortable with euthanasia, most of us in the scenario found it to be the right choice, but society goes against it.
Since words have to mean stuff, I would definitely call it immediate mode, it's not trivial at all to hack a generic retained mode UI library into being as flexible to what's on screen as ImGui. A generic retained mode design would more rather require pointers to some dependency state to check per update, with ImGui the schema gets rebuilt constantly, instead of being reactive. And there is definitely use cases for this design, constantly changing stuff would probably fit with Dear ImGui or others better than with a generic retained mode UI toolkit.
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.
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.
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.
Very nice. A parallel, I've been working on an emulator project recently, implementing my own disassembler, and I keep thinking about how I would turn patterns of machine code into a generalized form, which could then be turned into something like C-like pseudo-code, so it's been really compelling me lately to implement my own toy decompiler