Hello,
My current scenario: I need to write an application with a GUI that works on *nix, win, and osx (or whatever apple calls it these days).
What is my best option for this, in regards to GUI? Could I achieve this by using GTK? I have never seen GTK running on win or osx, so any and all comments would be appreciated.
Please, no web tech.
/Vjalmr
In case you didn’t know GNAT Studio (GPS) is GTK3. So yes, Windows and BSD (Mac stuff) are supported.
The choice is usually Qt or GTK. GTK tries to use look-and-feel of the host OS. Qt is available on a wider range of OSes. Another difference is that Qt is C++ and GTK is C. C++ is far more difficult to communicate.
In any case both have Ada bindings.
I use Gnoga a lot. It’s pretty handy at work for making some quick simulators and things when I want a GUI. It’s browser based, so that helps with cross platform scenarios. I only use Windows and Linux, but so far all of my stuff has compiled for both pretty easily.
Thank you, but I did specifically ask for non web tech solutions. I need something that comes as close to native as possible.
Oh gotcha, when you said web tech I thought you meant you didn’t want it over the web itself. Gnoga has local machine options. My mistake.
I am eagerly waiting for the release of LibreFrame: https://www.libreframe.com/
I would love to see if we can make a “native” rendering front-end for it.
Starting with something like RayGUI and maybe move to a full Ada implementation afterwards.
(I don’t know if the Sowebio people are hanging out around here)
Interesting, but does not look like a GUI at all.
To me GUI is all about widgets and handling events/messages. The problem with existing GUI like Qt, GTK, Win32 etc is abstraction inversion since handling events happens in wrong places. E.g. button press is handled by button widget rather that by a container of.
The event processing is unstructured and requires to be in front while the problem space logic is pushed back into callbacks.
Then of course, there is a push vs. pull problem. GUIs are built event-driven. This architecture is totally unsuitable for real-time, high-frequency and massive amounts of data applications where you would rather use polling. You can of course create an oscilloscope widget I did it in GTK and Win32, but it requires a lot of acrobatics.
No different from GTK so far. Construction of widgets you illustrated is never an issue. Event processing is also no different, you specified a call back function, what is worse in your code it has no parameters. E.g. in GTK it would be the button itself and the user data which can be turned into the event’s recipient. And, of course, it is 100% event-driven which is OK for some buttons (not for save-button, though, which might take seconds to finish) and never OK for an oscilloscope.
Maybe I misunderstand you or him, but I don’t think that’s a callback function in the same sense as what you have in, say, HTML DOM events. He could in fact have called a function with parameters; it depends on what he wants to do when someone presses the save button.
I say this also based on my own experience with immediate-mode GUIs, which I’ve used and actually dislike, though not for any good reason I can recall at the moment. But, as I say, perhaps I misunderstand you or him.
It depends on typing and marshalling. If a callback has parameters you need to marshal them to the call point. Even in an utterly untyped manner you cannot do that without specifying at least a closure at the point where you connect to an event.
I do not understand this drivel anyway. In all GUI I worked with you always can do rendering in an explicit manner. The problems begin with asynchronous events like when the widget gets covered, mouse hovers over it etc.
Dear Dmitri,
We’re trying a different approach. Give us a chance to show you something consistent. Time doesn’t respect what’s done without it. And there are, for the moment, only two of us.
For now, we’re taking care of the foundations by rewriting the websocket interface and using epoll. We’re now up to 1.5 M req/s on average hardware. But we can do even better. And we’ll do it if it makes sense. Like automatic reconnection, since websocket is obviously sensitive in this respect.
As this is still being settled, we also have a schedule to complete. Building - LibreFrame
Thanks for waiting a few months, but we’ll already have things ready between september and october this year.
We are, of course, always open to comments. We’re really counting on it.
All the best from Oleron Island.
Stéphane
Ada GUI project might be very interesting. Though it is a mammoth task I am not even sure how to approach it avoiding typical errors of GUI architectures.
Mentioning WebSockets in that context rings alarm bells to me. Anyway, good luck.
No difference again. You have messages processing loop in all GUI.
It is a basic primitive and crude functionality all GUI have. They try to abstract it away. E.g. by decomposing the procedure into individual primitive operations on the widgets like Draw.
So this video will probably remain the last thing I have to say about “IMGUI” programming for the forseeable future, except to add the fact that if you’re arguing about it, you probably don’t understand it very well.
On point 
Dear Dmitri,
Yes, websocket is natively very different from what we’re used to on the web.
However, the use of websockets is a key feature of Web GUI LibreFrame architecture.
In the age of fast, universal networks, permanent bidirectional communication (with the necessary precautions) could greatly enhance the user experience, compared with the classic transactional HTTP, with tons of JS…
To discuss this in more detail, I’d have to talk about LibreFrame’s complete architecture, which can be summed up as “everything from the server”. Indeed, in our concept, the amount of client-side JS is negligible.
To be user friendly, LibreFrame retains the entire user session, even across multiple tabs. LibreFrame emulates HTTP navigation. Arrows to return to a previous page or move forward are supported.
Similarly, loging out from a session with 10 tabs automatically close the 10 views. It’s a security enhancement. Loging again automatically restores them to the page they were on We’ve already demonstrated this at AEiC 2025.
As the icing on the cake, LibreFrame’s websockets communication protocol is designed to be very lightweight, and even works on 64 Kbps links (i.e. 0.064 Mbps :).
So, may be WebSockets, properly managed, could rings you some pleasent melody
And, yes, you’re absolutly right. LibreFrame, as a whole, is a mammoth task. But we’re tough. This project originated in 2020 with v20 library. By 2023-2024, we’ve reached a lot of milestones wth v22 framework, checked our assumptions, drawn up a schedule, and we’re moving on.
LibreFrame 1.0 will be on show at FOSDEM 2026, with applications already built using it.
We’re really looking forward to this first version to gather feedback.
All the best from Oleron Island.
Stéphane
The OP asked for a proper GUI rather than Web stuff.
Thank you, this looks interesting.
I did a little experiment with a native Ada IMGUI concept here:
It ended up just being a science project but might be interesting to folks here.
Uses the Ada SDL backend.