Question is why you are doing it. For what benefit do you hope with a GUI toolkit. Personally I would start with porting the C code to a modern high level language first. When the code is valuable and should be used and updated in future.
For the GUI part, I would assume that GTK supports that control flow, as it is sometimes used for installers. GTK has dialogs and Assistent, so it should be possible. If it makes sense is a different question.
If you’re referring to gtk_dialog_run(), then it was removed in GTK4 precisely because nested main loops and blocking behaviours are against the design of GTK. The existence of gtk_dialog_run() was pretty much just a concession to the kind of “stop the world” implementations that are common in CLI tools, but really have no place in a GUI—you cannot block processing of underlying asynchronous operations, and nested main loops have the tendency to break when it comes to threaded or out-of-process callbacks coming in while a blocking dialog is preventing any further update.
You cannot “port” a CLI tool, or an immediate mode UI, to a deferred, event-driven one. You have to fundamentally redesign the whole thing.
Good question about why am I doing this. The application is a prototype of a large system and used to run on MacOS Carbon. That has now gone away, so I am looking for a nice GUI toolset so that I can get the prototype to a point where it can be demonstrated again. Then funding could be raised and it could be ported to a more modern language for further development. So I am OK using a hack since the goal is to demonstrate a prototype. GTK looked like a great toolkit, but I am open to QT or any other mainstream solution.
I have been browsing the reference manual, and have come across:
gtk_main_iteration() and gtk_main_quit()
Does anyone have experience (or advice) with using these for this kind of approach?
Thanks!
while (1) {
gtk_main_iteration ();
if (gtk_main_quit_was_called)
break;
}
You still need to perform all operations within the main loop. You cannot just run your code, spin the loop, and then run code in response to that. That’s just how GTK works.
Plus, that API is gone in GTK4.
Qt has exactly the same requirements, by the way; the only difference is that you can feed Qt your own main loop implementation, which is why you can use GLib’s main loop to drive Qt applications.
Many thanks folks. I will stop looking at GTK and investigate imgui. Do you happen to know if there is a similar toolkit (to imgui) that is for C programs?
It sounds like this application is extremely old and predates the time when Macs could run more than one application at a time. A trick you could do might be to use a separate thread (or coroutine) for your app’s logic and then have it get fed events by a GUI thread.
I would only recommend imgui or nulkear if you don’t need accessibility support, as they don’t seem to support it at all right now. If you don’t need that, you could have good results with them.