https://github.com/tpecholt/imrad/blob/main/src/cpp_parser.h

Would appreciate if someone can explain, thanks!

[1] - https://en.wikipedia.org/wiki/Most_vexing_parse

https://www.lazarus-ide.org/

It’s Pascal instead of BASIC, which may or may not be an improvement depending on your perspective.

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.

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".

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.

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.

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

GAMBAS is the spiritual successor.

Same in Delphi / Lazarus. And the language was / is way more powerful.

Is Lazarus that fast?

Free Pascal is not as fast as Delphi 2 (especially if the target OS needs to use a native linker like GNU ld), for some decently sized projects it can take several seconds (or even a minute for multimillion lines of code) for a full build, though partial builds tend to be almost instant - at least in hardware released within the last 10 years (and SSDs help, like everywhere else). Of course both the language and the libraries (and Lazarus itself as an IDE and its own framework) do way more than Delphi 2, which itself was also more advanced than VB6.

I do believe that the provided functionality scales well with its requirements.

I'm not sure about a 400MHz P3, but i have tried a git build of Lazarus from last year on a late 2003 Athlon64 PC running Windows 7 and was very comfortable. A 400MHz P3 would be faster than an original Raspberry Pi, so i'd expect that if nothing else to be usable though might not be as comfortable as VB6 (or Delphi 2 for that matter). I do have a (IIRC) 800MHz P3 around for retro games, at some point i might try to install some lightweight Linux for fun and try to see how it performs there.

I used to use VB6 partly just for quickly drawing GUI’s, esp getting size right. Lazarus was one of free tools I found that was similar but most prefer other languages.

Is there a way to make a GUI in Lazarus, save it to a file with types/dimensions, and then some other tool could generate a non-Pascal GUI from it? Does it have an export ability that’s detailed and parsable enough for that?

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.

https://www.ultimatepp.org/

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.

If anything all these would be the (relatively) easy part, the hard part would be parsing C++ so that Lazarus can work with the code in there :-P.

Qt Designer exists, but PyQt/PySide licencing can cause headaches.

- 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).

For a large-scale real world project example consider that the NeXT version of Wordperfect was done is 6 weeks or so --- granted it started w/ a working Unix version, but it felt fully native and nicely polished (and was much better than the Windows version).

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?

I'm trying to work on it with https://slint.rs Our VS code extension has a drag and drop GUI editor.

You might want to check out PolyForm since they have source-available, proprietary licenses that might help in non-GPL cases:

https://polyformproject.org/

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...

more generally, guis that don't need to run constantly at xx fps don't have much reason to not be written in html5

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 :)

a gui that would use 100% of cpu on an 0.52-mips mac 512 https://netlib.org/performance/html/dhrystone.data.col0.html would probably use about 0.02% of cpu on one 2201-mips core of a raspberry pi 3 https://netlib.org/performance/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 1920×1080 instead of 512×342, 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

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.

but 9% is really very pessimistic. 0.05% is a more realistic number

users are 100% entitled to spend their resources on whatever apps they think is worthwhile, and of course to spend their time programming their computers as inefficiently or efficiently as they want

this should read '45 such apps concurrently'

So, yeah, there seems to be some desire for that kind of thing out in the wild these days.

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.

It has nothing to do with how the browser draws said html to the screen?

So you are just proving my point that this kind of discussion devolves into a semantic argument. You want to define rendering one way. Someone else uses the term another way. It's the same problem with "immediate mode" vs "retained mode". People just throw the words around assuming that everyone uses them the same way.

In this way, no discussion is actually had. Just a bunch of people insisting that their personal definition of a term must be adhered to.

1. https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...

Also, weren't you literally arguing in another thread that performance didn't matter? Some calculation about Raspberry Pis and percentages of cores? I'm starting to wonder how good faith of an argument is trying to be put forward here.

in case you mislead other people, though, i want to point out that 'imgui' is often used to mean both 'immediate-mode guis' and 'dear imgui', which can be confusing

I have some good memories.

> 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?

> 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

I really wish we'd go back to having a lot more RAD tools.

Forgot how to install and run native applications? :)

"ImRAD runs on Windows, Linux and MacOS."

Tell me how running a native binary is inherently easier than opening a webpage?

They're also the same number of steps. If I tell my OS to open an `html` file, it opens a browser window.

Wasm is great, but if the goal is to move native applications do the webb it isn't something I look forward to.

That would seem a little anathema to a imgui library aiming to be native on multiple platforms and to have minimum dependencies.

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...

Mind blowingly, webgl + Mac + integer textures still don't work afaik.

examples:

https://web.imhex.werwolv.net

https://floooh.github.io/sokol-html5/imgui-sapp.html

You also save time writing a ton of boilerplate.

> 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

Applications typically need good text rendering and layout support (multiline, fonts, maybe RTL, etc.), which ImGUI lacks.

once you got the hang of it you could really move quickly with desktop gui development