[HN Gopher] ImRAD is a GUI builder for the ImGui library
___________________________________________________________________
ImRAD is a GUI builder for the ImGui library
Author : davikr
Score : 205 points
Date : 2024-08-15 23:06 UTC (23 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| klaussilveira wrote:
| This is amazing. It might be my Visual Basic nostalgia kicking
| in, but this is the icing on the imgui cake for me.
| 29athrowaway wrote:
| To this date there's no RAD experience faster than Visual Basic
| 6.
| dlachausse wrote:
| Lazarus is pretty close and it's cross platform.
|
| https://www.lazarus-ide.org/
|
| It's Pascal instead of BASIC, which may or may not be an
| improvement depending on your perspective.
| badsectoracula wrote:
| I think "pretty close" is severely underselling Lazarus -
| it is _way_ ahead of Visual Basic 6 in almost every aspect
| when it comes to making GUIs. Even Delphi 2 (the first
| 32bit Delphi) allowed for more complex GUIs compared to
| VB6, let alone something way more advanced like Lazarus.
|
| The only thing that VB up to 6 had that you can't find in
| Lazarus (or Delphi for that matter) is being able to pause
| the program while it is running (or some error occurred),
| modify it and continue the execution without restarting it.
| But overall considering all the pros Lazarus has compared
| to VB6 i'd say it is much better than VB6 ever was.
| 29athrowaway wrote:
| VB6 was not very flexible in many ways but you could get
| an application going in no time.
|
| GAMBAS is the spiritual successor.
| FpUser wrote:
| "VB6 was not very flexible in many ways but you could get
| an application going in no time"
|
| Same in Delphi / Lazarus. And the language was / is way
| more powerful.
| pjmlp wrote:
| Which is available in .NET.
| stavros wrote:
| Lazarus seems amazing, and I'd love to write some
| software with it, but I can't get past the language. You
| generally do want to pick languages with a big ecosystem,
| as everything you might want will have already been
| written.
|
| The difference between Python and Delphi isn't a bit more
| work, it's often the difference between "there's a
| library so I can make my thing" and "it would take way
| too long".
| doublerabbit wrote:
| Pascal is a workhorse and to tame the horse takes a lot
| of skill and blind knowledge. And then when tamed, your
| horse is the best at the show.
|
| I can't fault Pascal. It may not have every module ever
| like Python, it's syntax may feel archaic but the
| satisfaction and feel of producing a program with is
| fuzzy feeling great.
|
| I enjoy making my own things, especially wheels.
| badsectoracula wrote:
| You can interface with existing libraries if you really
| want, you need to somehow expose a C ABI (be it via the
| library written in C, exposing an official C ABI or you
| writing a C bridge).
|
| There is a 3rd party "Python-for-Lazarus" bridge[0]
| though for simple stuff you can use the python library
| directly: program foo; {$MODE
| OBJFPC} uses CTypes; const PyLib =
| 'python3.11'; procedure Py_Initialize; cdecl;
| external PyLib; function
| PyRun_SimpleString(Command: PChar): CInt; cdecl; external
| PyLib; begin Py_Initialize;
| PyRun_SimpleString( 'from tkinter import
| *'#13 + 'window = Tk()'#13 +
| 'window.title("Hello, world!")'#13 + 'button
| = Button(window, text="Clicky")'#13 +
| 'button.grid()'#13 + 'window.mainloop()');
| end.
|
| The above uses the Tk library that comes with Python.
|
| Also depending on what you want to do chances are there
| is already a Free Pascal library or existing bindings to
| a library written in another language. If not, if the
| library has a C header file you can use the h2pas utility
| that comes with FPC to make your own (though the
| generated code does need some modifications to work more
| often than not).
|
| Of course all the above do assume you have knowledge of
| both Free Pascal and whatever you want to interface with,
| but at least as far as being able to _access_ existing
| libraries is concerned, it should be possible - just with
| some hoops (and at that point it depends on how much you
| value whatever Lazarus provides over the effort involved
| in whatever library you want to use).
|
| EDIT: and truth be told IMO the biggest roadblock with
| Lazarus isn't so much the language but that it is just
| not easy to learn most of that stuff (the core language
| and runtime library is decently documented but anything
| outside of that can be a hit and miss) and you basically
| need an almost arrogant attitude of "this is just dumb
| code, not magic, if it is technically possible i can
| figure out myself how to do it" :-P.
|
| [0] https://github.com/Alexey-T/Python-for-Lazarus
| nickpsecurity wrote:
| VB6 also used to start in about one second on a 400MHz
| P3. Test runs on the programs were about as fast. I had
| no mental pauses for compile times.
|
| Is Lazarus that fast?
| zerr wrote:
| I wish it had C++ support as well, akin to C++Builder.
| Pascal syntax is off-putting for many.
| lelanthran wrote:
| > I wish it had C++ support as well, akin to C++Builder.
| Pascal syntax is off-putting for many
|
| I write my "app" as a library (.dll/.so) in C and use
| Lazarus to do the GUI, because FFI from FreePascal to C
| (and back again, for callbacks) is almost transparent.
| zerr wrote:
| Well, I like using C++ for UI.
| nazgulsenpai wrote:
| Have you ever tried U++? I haven't used it beyond quick
| and dirty testing but has a decent GUI builder and is a
| full C++ IDE.
|
| https://www.ultimatepp.org/
| klaussilveira wrote:
| Thank you, I did not know about this!
| badsectoracula wrote:
| It'd be neat but that would require a ton of effort and
| cooperation by several different projects.
|
| Basically you'd need a C++ compiler to implement the C++
| extensions used by C++ Builder (or something similar if
| you don't care about C++ Builder compatibility) so that
| C++ code can use Object Pascal methods with the extra
| functionality it adds (most important being properties
| and "published" sections in class declarations that are
| exposed via RTTI). You'd also need some tool to create
| C++ bindings for all the Free Pascal units.
|
| The above will make possible to use LCL from C++, though
| only via code.
|
| To get the full RAD deal you'd need to implement a C++
| parser (including the extensions mentioned above) and
| refactoring support for Lazarus' CodeTools equivalent to
| the existing Free Pascal parser/refactoring so that the
| IDE can autogenerate code (Lazarus doesn't generate
| separate source code files like some other IDEs with GUI
| designers do, instead it updates the same source code you
| are editing on the fly as it keeps a full AST in memory
| for all edited files and units they depend on - something
| like that would be needed for C++ too).
|
| And yeah, you'd need the people involved with all the
| above (really mainly the C++ compiler developers) to play
| along without breaking stuff.
| sedatk wrote:
| Delphi could run circles around VB6.
| pjmlp wrote:
| Delphi, C++ Builder, WinForms.
| varispeed wrote:
| Microsoft WPF was great as well. I thought they killed it,
| but seems like the project is still active.
| scrlk wrote:
| Given that Python appears to be the new VB6/VBA (in terms of
| adoption by a non-SWE user base), IMO there's still a gap for
| a decent VB6-like RAD experience within the Python ecosystem.
|
| Qt Designer exists, but PyQt/PySide licencing can cause
| headaches.
| WillAdams wrote:
| I'd give a lot for there to be a simple tool for Python
| which:
|
| - had an interactive tool for laying out a GUI
|
| - integrated that layout into the code in a meaningful
| fashion
|
| - allowed distributing a project as a single file which
| could be easily run (say by downloading/installing a single
| run-time module)
|
| The problem is, for each computer I use I need to keep
| track of which Python environment(s) have been installed
| where, (and uninstall them) or I end up with something
| like:
|
| https://xkcd.com/1987/
|
| (well, at least something which won't allow me to get a new
| project installed).
| reddit_clone wrote:
| How about Delphi 6 ?
|
| I have some good memories.
| nottorp wrote:
| ... or a more full featured experience than Delphi.
|
| VB fails (or used to, haven't worked with it in a looong
| time) when you want to do custom controls and integrate them
| in the UI builder. With Delphi that used to be piss easy, you
| could even write designer-only methods that helped with
| custom configuring your controls, while with VB you had to do
| it in something else iirc. Too bad Embarcadero only wants to
| sell to enterprises that are stuck on legacy applications.
|
| And what's with all the Pascal hate? Missing your <> and {}?
| Nothing wrong with begin and end.
|
| What I wonder is: if the Rust crowd is hell bent on rewriting
| everything, why don't they clone the VCL and the GUI
| designer?
| kragen wrote:
| i think most guis in 02024 are built in html5, godot, or
| unity rather than vb or delphi vcl. so i'm not sure cloning
| the vcl would be so useful
| nottorp wrote:
| Godot or Unity? Why would you build a regular application
| GUI with that?
|
| Those are for running a game or game like application
| constantly at XX fps, not for something that reacts to
| user input and should consume 0% cpu when it's not told
| to do anything.
|
| Please tell me "modern" UI toolkits are still event
| driven and don't infinitely render everything in a loop
| like a game...
| kragen wrote:
| the thread you have (apparently unintentionally) posted
| this comment in is entitled 'ImRAD is a GUI builder for
| [an] ImGui library [for opengl]' :-)
|
| more generally, guis that don't need to run constantly at
| xx fps don't have much reason to not be written in html5
| nottorp wrote:
| Oh :(
|
| I thought ImGui was a regular GUI library.
|
| Why are people even mentioning VB6 and Delphi then in the
| comment threads?
|
| Possibly because they made the same assumption that I
| made :)
| kragen wrote:
| imgui is a general approach to designing gui libraries
| proposed by casey muratori in 02005
| https://www.youtube.com/watch?v=Z1qyvQsjK5Y; the
| particular library in question is omar cornut's 'dear
| imgui'
|
| a gui that would use 100% of cpu on an 0.52-mips mac 512
| https://netlib.org/performance/html/dhrystone.data.col0.h
| tml would probably use about 0.02% of cpu on one
| 2201-mips core of a raspberry pi 3 https://netlib.org/per
| formance/html/dhrystone.data.col0.html
|
| if you pessimistically multiply that by 32 to account for
| having 32 bits per pixel instead of 1, and by 12 to
| account for 1920x1080 instead of 512x342, it comes to 9%.
| of one of the cores! also it would run in 0.5% of the
| pi's ram
|
| so, to a significant extent, the struggle is no longer to
| get something approximating your desired user interface
| running, but to imagine a user interface that's worth
| people's time to use. so it makes sense to trade off cpu
| consumption and ram usage for faster experimentation in a
| lot of cases
| nottorp wrote:
| > it comes to 9%. of one of the cores! also it would run
| in 0.5% of the pi's ram
|
| 9% from one app, 9% from another, pretty soon we're
| talking about real power consumption / battery life
|
| And even the 9% that you find trivial is something I, as
| an user, could use for something that gives me a benefit
| instead of your game-like GUI.
|
| > so it makes sense to trade off cpu consumption and ram
| usage for faster experimentation in a lot of cases
|
| It does not. If it has nothing animated, you'd better not
| redraw it. Anything else is lack of respect for the
| user's resources.
| zoogeny wrote:
| I recently saw a tweet where a programmer demanded that
| all UIs (and presumably their frameworks/toolkits) should
| be immediate mode.
|
| So, yeah, there seems to be some desire for that kind of
| thing out in the wild these days.
| kragen wrote:
| react is immediate mode, and it doesn't have to refresh
| at xx fps; it only refreshes when a change in the data
| the gui is dependent on. (and the browser tends to
| refresh when there are input events)
| zoogeny wrote:
| This is the kind of thing that can easily devolve into a
| semantic argument. React presents an immediate mode like
| API but internally (both in the virtual DOM of React and
| within the actual DOM of the HTML document) the actual
| rendering path is very much retained mode.
|
| The specific thread we are in isn't related to the
| benefits/drawbacks of API design but rather the
| performance implications of re-rendering the entire scene
| on every frame. As you mentioned, React doesn't re-render
| on every frame and therefore isn't really relevant to
| that discussion.
| ogoffart wrote:
| > if the Rust crowd is hell bent on rewriting everything,
| why don't they clone the VCL and the GUI designer?
|
| I'm trying to work on it with https://slint.rs Our VS code
| extension has a drag and drop GUI editor.
| nickpsecurity wrote:
| I like your licensing setup with GPL, community, and
| different deployments. Good flexibility.
|
| You might want to check out PolyForm since they have
| source-available, proprietary licenses that might help in
| non-GPL cases:
|
| https://polyformproject.org/
| dsp_person wrote:
| This would be cool built in a wasm html5 app to whip up a gui in
| the browser and copy paste the result into your editor.
|
| > It generates and parses C++ code which can be directly used in
| your application.
|
| Is the parsing part just to read it's own code it generates?
| nottorp wrote:
| > This would be cool built in a wasm html5 app to whip up a gui
| in the browser and copy paste the result into your editor.
|
| Forgot how to install and run native applications? :)
|
| "ImRAD runs on Windows, Linux and MacOS."
| dymk wrote:
| Opening up a webpage is easier than cloning a repo,
| compiling, and running a binary
| tjoff wrote:
| ... if you only do it once.
| dymk wrote:
| Okay, for the sake of the argument, let's assume at some
| point you amortize the fixed costs of native compilation
| down to zero.
|
| Tell me how running a native binary is inherently easier
| than opening a webpage?
| marcodiego wrote:
| To open a webpage you have first to run a native binary.
| So, running a native binary is necessarily easier than
| opening a webpage.
| dymk wrote:
| You are confusing "Number of steps" with "Easy".
|
| They're also the same number of steps. If I tell my OS to
| open an `html` file, it opens a browser window.
| marcodiego wrote:
| If doing task B requires doing task A first, then doing
| task A is necessarily easier than doing task B.
| strawhatguy wrote:
| I think you're confusing "simple" and "easy". One task vs
| two is simpler, yes.
| tjoff wrote:
| The performance and user experience of a native binary is
| on a whole other level.
| dymk wrote:
| It's really not with wasm. Sure, there is a performance
| difference. It is not a "whole other level".
| chrsig wrote:
| which is actually pretty often for a demo!
| ddtaylor wrote:
| "You guys do have phones, right?"
| _aavaa_ wrote:
| > wasm html5 app
|
| That would seem a little anathema to a imgui library aiming to
| be native on multiple platforms and to have minimum
| dependencies.
| dymk wrote:
| A multi-platform, minimal dependency project such as this is
| a perfect fit for targeting wasm, which of course is "just"
| another platform (not sure what additional dependencies you
| think it would need?)
| joshcryer wrote:
| ImGUI generally runs on GLFW and there is even a port to
| html5: https://github.com/jnmaloney/WebGui
|
| ImRAD appears to be based on GLFW as well so one would only
| have to follow a tutorial:
| https://uncovergame.com/2015/01/21/porting-a-complete-c-
| game...
| jasonjmcghee wrote:
| WebGL2 is a thing now so some of what that blog discusses
| isn't as bad anymore, in terms of shader support.
|
| Mind blowingly, webgl + Mac + integer textures still don't
| work afaik.
| dsp_person wrote:
| it's easy nowadays to compile imgui apps to wasm/html5
|
| examples:
|
| https://web.imhex.werwolv.net
|
| https://floooh.github.io/sokol-html5/imgui-sapp.html
| dymk wrote:
| The parser:
| https://github.com/tpecholt/imrad/blob/main/src/cpp_parser.h
|
| > Is the parsing part just to read it's own code it generates?
|
| It would seem so. Their hand-rolled parser handles only a
| subset of the language. E.g. it hard-codes recognition for stl
| containers, and presumably only the ones that it might emit in
| generated code.
|
| There's no AST built, at least not at this level. It tokenizes
| and lexes, and seems to leave it up to the caller to understand
| how to pump the parsing "state machine".
|
| AST building and codegen appears to be done in this >9000LOC
| file - https://github.com/tpecholt/imrad/blob/main/src/node.cpp
| giancarlostoro wrote:
| I've thought about making a RAD IDE for another language, and
| I'm kind of stuck wondering on strategies for stuff like
| this, I'd much rather just store the GUI info in another
| format like XML and only parse source files for things like
| methods that shouldn't be overriden when someone moves
| something.
|
| I really wish we'd go back to having a lot more RAD tools.
| waynenilsen wrote:
| Makes me miss netbeans
|
| Now do the same for tailwind
| pjmlp wrote:
| Still using it on personal Java projects.
| waynenilsen wrote:
| the codegen that thing had for frontend was excellent in
| later versions
|
| once you got the hang of it you could really move quickly
| with desktop gui development
| tecleandor wrote:
| Is the C++ generated code usable from, for example, Python when
| using pyimgui bindings?
| joenot443 wrote:
| This is fantastic. I've spent the last couple years working on an
| ImGui C++ app, this would have saved me many hours.
| BatFastard wrote:
| I am just starting with imGui, tell me how this will save me
| time please?
| consteval wrote:
| You can see the interface while you're designing it. Meaning,
| instead of writing a bunch of code, compiling, running,
| deciding one widget needs to be moved a bit you can just see
| it and move it.
|
| You also save time writing a ton of boilerplate.
| exe34 wrote:
| I don't think there should be so many sudos in there. otherwise
| looks really cool!
| secondary_op wrote:
| Why is GUI builder for ImGui is not implemented in ImGui itself ?
| flohofwoe wrote:
| What makes you think that it isn't? Looking at the code and
| screenshot it uses Dear ImGui for its UI.
| 9erdelta wrote:
| Awesome, I've been working on a project with ImGui and keep
| thinking how great something like this would be. I'll be trying
| this out!
| dymk wrote:
| Perhaps one of the most mind-boggling parts of this project is it
| has a hand-rolled parser for the subset of C++ that it can emit.
| All implemented in a single header. Equal parts impressive and
| crazy.
|
| https://github.com/tpecholt/imrad/blob/main/src/cpp_parser.h
| syeare wrote:
| What does this comment mean? Since not particularly well-versed
| in programming, all I understood was that this project has
| something that can read data? What is impressive about a tool
| that can read C++?
|
| Would appreciate if someone can explain, thanks!
| dymk wrote:
| C++ is a notoriously difficult language to parse [1], so
| hand-rolling a parser (even for a subset of the language) is
| an impressive feat. It's also interesting that they decided
| to implement their own tokenizer and lexer instead of using
| something "off the shelf".
|
| [1] - https://en.wikipedia.org/wiki/Most_vexing_parse
| supportengineer wrote:
| Steam is a popular cross-platform system, could it ever be used
| for non-gaming applications? Even Enterprise applications?
| webkike wrote:
| I'm not sure why you're bringing up Steam, but they do sell
| software on it
| andsoitis wrote:
| > could it ever be used for non-gaming applications? Even
| Enterprise applications?
|
| Applications typically need good text rendering and layout
| support (multiline, fonts, maybe RTL, etc.), which ImGUI lacks.
| lainga wrote:
| Shouldn't it be "for the Dear library" given that the dear-imgui
| creator has stated it's named "dear"? (IMGUI means immediate-mode
| GUI, and ocornut has said he was inspired by another IMGUI named
| "simgui" [] )
|
| > I renamed it to "dear imgui" (about 15 months later) because
| "imgui" has been hogging up the whole acronym. I am sorry for the
| confusion caused even today.
|
| [] https://github.com/ocornut/imgui/issues/7892
| TillE wrote:
| Dear ImGui is the full official name, but it's still extremely
| common to refer to it simply as ImGui (that's what the
| namespace is called, etc). It's definitely not just "Dear".
___________________________________________________________________
(page generated 2024-08-16 23:01 UTC)