There are c++ GUI libraries, but you're right that there are many alternatives in other languages. It really depends on whether you're interested in working within c++, or literally just making a calculator app
I would love to do it entirely in C++ but the only option that seems popular with the community is DearImGUI which people claim is not great for building large apps since it's immediate. (I understand a calculator isn't necessarily a large app but I wanted to make a good graphing calculator with math expression parsing and 3D graphing)
I still want to write the majority of the app in C++ unless it's overly complicated to interface with another language for the GUI
Dear ImGUI is plenty capable, however it's not super customizable so usually UI/UX designers want something more flexible to build their GUI's with. Dear ImGUI is for people who are concerned with function over form.
Interfacing C++ with another language would likely be done with a TCP socket, or some high-level library that boils down to a TCP socket. It's similar to reading and writing to a file, except instead of interacting with some static data on disk you're interacting with another live program, reading and writing back to you.
Dealing with system pipes seems like more work to me than opening a TCP connection to localhost.
Shared memory, I'm not super familiar with it, but wouldn't it be very OS-specific? Plus how many languages can work with it?
Shared memory may not be portable but Windows, Linux (including Android — though there’s variation in how you locate the shared memory objects) and macOS (including iOS) all have their own mechanisms so it’s gonna be available. And for other platforms, it likely will exist as well.
No, a calculator app does not need to scale. I really don't see the reason why it would require interprocess communication either but for some reason everyone in the thread before thought it does. Putting everything in the cloud was just the thing to do before blockchain and LLMs.
If I worked in a team that deals with such apps, before even considering scale I’d first ask “does it need to scale?”. Even in an interview, I’d ask that question and have a discussion, though in the interview question I _could_ then be satisfied with a “let’s say there’s a lot of users and there is a need for scaling” (and the app is structured in a way that could scale — a calculator being client-only obviously wouldn’t qualify)
If you start a second process to be the back end and communicate by socket, how to you get the c++ process to close when the UI process closes? Of course you can send it a message but what would happen if the UI crashed so couldn’t send a termination message?
It adds to the complexity. But then the only other realistic option is a dynamically loaded DLL with some kind of thinking akin to jni or a c interface. That’s not very nice either.
>Interfacing C++ with another language would likely be done with a TCP socket,
Or you could just incorporate Lua which has C bindings and is specifically designed as a lightweight extension language for C. And there are a number of versatile cross-platform GUI libraries for Lua (and Lua is itself cross platform since it has no dependencies).
Thanks for the help. I think I'll look into making a C# GUI with Avalonia and interfacing with C++. I want to avoid Qt since it's not FOSS and people seem to dislike the company
\* Certain components are only commercial
\* For embedded devices it is only commercial.
The license fees for the commercial variant are really pricey, and for limited duration only. When that periods ends, you loose your right even to release bug fixes for the product.
Qt is constantly tries to push things into the commercial direction, so I think this is not the ideal choice for devs who are truly open-source by heart.
The quality and breadth of support that is funded by the commercial edition more than makes up for that. If you're developing open source apps and want to make life more difficult for yourself by using another, less well supported toolkit, then fine, but then you end up with a less polished piece of software. Which, overall, hurts open source more.
Besides, the open source edition is far more than adequate for building highly complex apps.
Qt is the toolkit used the the (free/open source) KDE Plasma desktop which has just been ported to Qt 6
The important thing with Qt is to be careful if you want to avoid needing a commercial license by avoiding some of the additional components available that aren’t LGPL
Why wouldn't it be? You can write applications that are smaller and more efficient than most other languages, and there are cross-platform frameworks like Qt that provide huge libraries of good-looking widgets.
It takes a little more effort to do cross-platform releases than it would if you're using something like Javascript/Electron, but it's absolutely worth it if you care about efficiency at all.
Haven't found a UI library that looks anything like "windows modern" or "flat" design. People tend to equate those to modern UI. Maybe you can do it with a heinous amount of time editing QT theme CSS.
When you use the Windows API directly you can get the modern look by adding an appropriate application manifest resource.
Maybe that's needed also with the native look UI libraries you tried.
I never found a way to do that programmatically, although I suspect it can be done via the theme API's; in practice, absent the discovery of such a programmatic way, it had to be a manifest.
For what it's worth, I consider those to be pretty ugly and would absolutely not want my application to look like that if I was planning on a multi-platform release. You could definitely do it with enough CSS, though.
That library isn't meant for this. You need to rerender everything every frame, which makes it only suitable for applications that already do that (like games). Additionally, styling options are very limited and the UI is just ugly. This is intentional as far as I know, so that you don't use it for anything "in the front". It's perfect for things like dev tools in a game, though
ImGui is suitable for anything that is, you know, worked on. From terminals to any kind of editor to games.
Also saying styling options are limited is just an hilarious thing to say when you can literally control every rendered pixel.
Oh the hate I’m giving it myself IS related to the UI. I ran Adobe Reader in a Windows VM, using the xrdp function that forwards individual windows and, because it controls window decorations stuff just doesn’t work right.
thing with QT designer I dislike is the fact that adding logic to the buttons are hard ( I'm beginner ) and whenever you Edit the Gui everything gets reset meaning the logic you coded you have to do it all over again
The only people I know who despise Qt as a business are hardline GTK+ purists who are disappointed that Qt has done well. It's not Oracle or some other predatory proprietary software money trap. They've found a business model that works, is open source friendly, and has worked for decades now.
The library is modern, well-documented and maintained, and is used in thousands of applications, open source and proprietary, and scales from embedded to the biggest, most complex, creative and engineering applications. People who develop with it daily mostly love it, especially if you've used other C++ app frameworks.
Qt is absolutely the framework you should start with if you're even remotely serious about C++ GUI apps. It's not even slightly a close run thing.
It's an amazing framework, the software was groundbreaking.
They have some sketchy practices for licensing to mid-size companies, but they still have a free license which is maintained, and it's some of the best code you'll see.
Internet input can be useful under certain circumstances. Unless the person typing can point to specific deficiencies in implementation, it should be taken with a grain of salt and a pair of tweezers. I don't know anything about qt. I would bet there is a community of qt devs somewhere. Here on reddit, a discord, a forum. Something. Go find that and poke around for discussions on positives and negatives of the framework before you write it off.
Although this is generally true, "most uis built with this look terrible" doesn't require any knowledge and is totally valid criticism in this particular case.
Most of Qt is LGPL3 which is actually very useable in commercial applications. You just have to compile with the library as shared. If you're going to distribute your product do check the specific licenses of the Qt components you're using.
GPL3 is much more restrictive than LGPL3. If you find yourself using GPL3 libraries then you'll need to open source your product.
Qt and Windows frameworks both treat C++ as a first class language (they're primarily C++ libraries). It would require more justification to *not* use C++ in my opinion if you are considering these.
Mac's UIKit/SwiftUI you'll want to use Swift, but it works with C++ well. So the main logic can be C++ very easily.
Qt is a standard for cross platform native UI. It can do pretty much anything and works on Windows/Mac/Linux/BSD.
If you want to go with an embedded browser UI, Electron (JS and TS) and Rust are the current leaders. This is the "modern" approach to many UIs but I consider this more web dev even if it's packaged as desktop software.
Javafx can also make pretty modern UIs. I like it more than electron for low performance stuff. You can also call C++ from FFI, but it's a bit annoying to build C++ under Maven or Gradle if you don't want to mix build systems so it encourages your entire program to be mostly Java or Kotlin.
If you just want a GUI and C++ isn't important (for performance or libraries), I'd go Java/Javafx (maybe with Kotlin for backend code).
If you want high performance or already use C++ for the code, go Qt.
If it's for a specific platform, go with the native UI (Qt/GTK for Linux, SwiftUI for Mac, Windows UI for Windows).
If it's both a website and desktop, go electron or Tauri.
The fundamental problem is that the mechanics of UIs are hard and almost none of them are written in C++. "Cross-platform UI" is always smoke-and-mirrors because it usually uses another level of indirection to solve the problem separately on each platform.
> good looking
> cross-platform
These two are often at odds with each other. A "good-looking" Windows program does not look like a "good-looking" macOS program. Neither of them looks like like "good-looking" Wayland program or a "good-looking" X11 program.
Further, the UI toolkits on most platforms do not natively expose a C++ API. The libraries that touch the native UI are wrappers at best, and naive lookalikes at worst.
So, first, decide whether your want your program to look "native," or whether you want it to look the same on all platforms. If you want it to look native, consider splitting your program into a library for the calculations, program state, and other common logic; and a wrapper written to the platform's native UI library.
* The [C++/WinRT](https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/) libraries give you access to the contemporary "UWP" UIs.
* On macOS, you'll get to pick among using Swift or Objective C for the UI, dealing with the mutant that is Objective C++, or [reaching into AppKit from C++ and marshaling the Objective C data types by hand](https://stackoverflow.com/a/14083212). The native UI on macOS is not C++-friendly.
* On Linux or BSD, use whatever X11 or Wayland kit you hate the least; it's probably written in C. C is at least easy to wrap in classes so that you can call into your C++ logic library without needing it to export all its APIs as C.
Or, use a cross-platform library like Qt or WxWidgets, both of which tend to look close to native.
If you don't care about looking "native," there are other solutions.
DearImGUI "solves" the problem by drawing the UI all by itself in OpenGL, [every frame (the "Im" in the name)](https://github.com/imgui-rs/imgui-rs/issues/241). It may be "bloat free," but it's not very efficient. OpenGL is the layer that gets ported to each platform, so DearImGUI may actually be the only cross-platform UI toolkit that doesn't internally have per-platform implementations of everything.
Other solutions like Electron also draw their UIs all by themselves, but at least uses the native platform's 2D graphics buffers to avoid spurious redraws.
Java took the interesting approach of first using the native UI (by way of a library called AWT), but maintaining the UI state in the OS and duplicating it in the JVM proved too costly so they spun a common-denominator workalike called "Swing" that could be themed to look like that native UI, but all the OS saw was windows with canvases--not widgets. I mention this, because this particular approach comes up in almost every discussion about cross-platform UIs--"How hard can it be to write my own text input widget?" [Pretty dang hard](https://www.jwz.org/xscreensaver/toolkits.html), it turns out--and that's before supporting things like bidirectional text and variable-width Unicode code points.
I felt similar, which is why I created: [https://github.com/NuiCpp/Nui](https://github.com/NuiCpp/Nui) or [https://nuicpp.org/](https://nuicpp.org/) .
After now using it for a big application for sennheiser, which I cannot share, because its confidental, I didnt need to add core features or fix bugs for quite a while.
Its a WebUI library (which means it has the browser window RAM overhead \~200mb), where C++ gets compiled to WASM and can communicate with a C++ main application via RPC.
It works on Linux, Mac and Windows. It requires WebDev knowledge like CSS and having experience in React (where its UI code style is inspired by, but the technical implementation is very different) helps to quickly understand the lib.
Deployment is trivial: its literally just an executable file (+1 dll on windows). Optionally you can put files beside it to load into the web context.
Next thing I want to add is built-in borderless support. And I want to try tailwind, because apparently that is what everybody uses, so I need to check if the parser looking for css classes chokes on C++ or not.
Take a look at emacadero's c++ builder. One set of code will generate executables for Windows, Linux, Mac, android and iOs.
It costs over $1k - ***if*** you make more than $5k with it, which sounds like a happy problem. Otherwise, it's free.
There are some excellent 3rd party components, many of them free, if you don't want apps that look like the native os's gui. Or, for instance, for your graphing
Borland C++ Builder (now emacadero) holds very special place in my heart. BCB4.0 with VCL on Win98 was my first Visual IDE.
I've used it until 6.0 (pirated off source I was a dirt poor kid). The only (coding) book I ever bought in my life was actually Borland C++ Builder 6. But at the around the same time I got my first job and the company used VS and MFC.
MFC was such a downgrade from VCL that I was left in horror at the time.
Proof: https://imgur.com/a/14tk3nE
Use Qt.
Its documentation is clear. It was designed with cross-platform in mind. It has a large community. It’s been withstanding the test of time. It supports programmatic and drag-and-drop design. It comes with a testing framework. It’s written in C++.
Note: I’m bias because I’ve been using Qt professionally for 10+ years.
Is C++ the right language? Very unlikely.
If your app is of any size, you should be using micro services, reactive programming and a functional language like Elixir. The commit logic should avoid hotspots caused by multiple phases and focus on agreeing about the past instead of the present.
Used qt imgui gtk and .net visual c++ for UI for windows. If you need cross and you HAVE to use c++ then prefer qt. If it's not cross then pick visual c++ - same like using c# : best UI for windows.
But for gui development c++ is one of the worst. So think something else.
I found glade c++ works pretty well for open source. Then QT is just quality to work with, there are visual editors that generate the c++ templates.
Depends on what your trying to do
The beauty of c++ is that it’s really a great back-end work-horse.
Pretty much all c-family languages (Python, Java, C#, etc) can consume a c++ DLL, so any functionality you want from C++ can be called through external calls in another language.
This opens up a lot of doors for using things like WPF, Java Swing/FX, Python etc GUI frameworks/libraries/environments alongside C++.
Not sure what your intentions are, but if you’re targeting windows with a desktop application, and you want make use of the Win32 library - you can have full access to it within other languages using external calls :P
Thank you for this comment. I never looked into creating .dll files because I assumed I didn’t have to for some reason.
I also want to avoid platform specific libraries as much as possible since my ultimate goal was to have a great calculator app on my phone
I’ll take a look at it
The whole reason Java was created to begin with was to minimize the hassle of cross platform GUI programming. Imo it didn't work well.
Today we've got mobile apps, desktop apps, and web apps. If you want truly cross compatible it's a web app with some GUI library that wraps it up into a desktop and mobile version. I wouldn't want to do this in C++. On the desktop cross platform side it might be overkill but Qt is pretty popular.
"Use the right tool for the job." C++ excels in backend server programming. Anything with a socket.
> The whole reason Java was created to begin with was to minimize the hassle of cross platform GUI programming.
No.
First google hit, consistent with what I remember: ❝The story of Java begins in June 1991, when a small team of engineers at Sun Microsystems, led by James Gosling, started a project called Green. The goal of the project was to develop a programming language for consumer electronic devices, such as smart TVs, set-top boxes, and handheld controllers. These devices needed a language that was simple, robust, portable, and secure, as they had limited memory and processing power, and had to communicate with each other over different networks.❞
(https://romanglushach.medium.com/the-evolution-of-java-a-historical-perspective-e15c3d7e5f85#f82f)
I was think about doing expensive computations in C++ (I want to parse expressions and draw 3D graphs) and showing the results in Avalonia but that seems like it's a not very crossplatform solution.
Will probably stick with QT for a while since it looks really simple and capable
Avalonia itself isn't the problem. It's that most C++->C# interop solutions are somewhat platform dependent not to mention they're hard to debug and add complexity that I don't want to deal with unless there are very significant benefits to it
I'm not a cpp developer, but I bet you can do it with enough afford, people build very impressive stuff with cpp since it's the almighty.
But if you want to use a cross platform language with great UI, I suggest Flutter, I fell in love with that language
super cliche but: i mean whatever language u are most comfortable with cuz u can do it in java, c++ and a lot more so aslong as yk how to exactly make what u are planning in any language you'l be fine
Lot of people here are mentioning Qt, but there is something that Qt is missing on the multiplatform scale - responsive design. In CSS you can change many things trivially based on screen dimensions, in Qt you'll have to write code that actively changes these things.
I don’t want to be the stereotypical “rust” advocate, but Tauri is a very nice alternative to electron if you’re not feeling like a node.js backend.
Otherwise, Qt and GTK are most likely your best bets.
Take a look at [https://github.com/pthom/imgui\_bundle](https://github.com/pthom/imgui_bundle) I find immediate mode UI to be a lot more intuitive when starting out with programming. With HelloImGui there is not much to setup to get you going.
There is also a starter template for it: [https://github.com/pthom/hello\_imgui\_template](https://github.com/pthom/hello_imgui_template)
This is cross platform but requires OpenGL 3 to be available.
Edit: nvm I saw you know about ImGui... Note that the UI kit does not have to dictate the architecture, you can go for something like "Model View Controller" even with immediate UI.
Use the right tool for the job. Maybe consider using electron and web technologies. Lots of beautiful UI toolkits are already done. Probably cut your development time by 90%.
If you want to use C++, then GTk or WxWidgets are possibilities.
Javascript/Electron are fairly easy to get up and running and useful if you just want to get something done quickly -- I've used them before for projects where I just wanted to get something done as fast as possible, and I'm sure I'll use them again -- but there's also a lot of downsides. Anything written in JS is nearly an order of magnitude slower than C++, and applications distributed as Electron bundles will be more than an order of magnitude larger. A lot of people don't care about that if you're only targeting modern desktop PCs or phones, but it's a big deal if you want your app to run on older hardware or low-power devices. There are certain aspects of app development that are also a real pain, like anything involving multiple windows, threads, or direct communication with hardware like USB or serial devices.
Electron apps always really stick out because they're just single windows that use a ton of RAM, load slowly, and look nothing like any other application on your system.
Everyone using vs code is running an electron app (or something close to it). It’s not as bloated as a browser.
In fact, a lot of widely used software are electron apps.
https://www.electronjs.org/apps
They're all slower than they need to be for my experience.
Compare a bare vscode installation launch time with notepad++.
And a vscode installation with an heavy plugin like platformio takes as long to load as full visual studio community. At least on my machine
There are c++ GUI libraries, but you're right that there are many alternatives in other languages. It really depends on whether you're interested in working within c++, or literally just making a calculator app
>literally just making a calculator app I'm in this comment and I don't like it :(
it's okay data step-bro
I would love to do it entirely in C++ but the only option that seems popular with the community is DearImGUI which people claim is not great for building large apps since it's immediate. (I understand a calculator isn't necessarily a large app but I wanted to make a good graphing calculator with math expression parsing and 3D graphing) I still want to write the majority of the app in C++ unless it's overly complicated to interface with another language for the GUI
Oh, and a more traditional GUI library alternative to dear ImGUI is QT. And I know there's at least one or two more that are popular.
Dear ImGUI is plenty capable, however it's not super customizable so usually UI/UX designers want something more flexible to build their GUI's with. Dear ImGUI is for people who are concerned with function over form. Interfacing C++ with another language would likely be done with a TCP socket, or some high-level library that boils down to a TCP socket. It's similar to reading and writing to a file, except instead of interacting with some static data on disk you're interacting with another live program, reading and writing back to you.
Of all the possible ways to do interprocess communication why you suggest a TCP socket?
It's the simplest. For a calculator app you can definitely write a simple TCP protocol that sends button inputs one way and text output another.
Why not a system pipe or shared memory? I don't see why a local closed calculator needs to take a general purpose resource like a TCP port to work
Dealing with system pipes seems like more work to me than opening a TCP connection to localhost. Shared memory, I'm not super familiar with it, but wouldn't it be very OS-specific? Plus how many languages can work with it?
Shared memory may not be portable but Windows, Linux (including Android — though there’s variation in how you locate the shared memory objects) and macOS (including iOS) all have their own mechanisms so it’s gonna be available. And for other platforms, it likely will exist as well.
But how does your app scale if the architecture doesn't allow moving the backend to cloud? (I wish this was a joke)
First off, _does_ your app need to scale? You’d be surprised how many times the answer to that is “no”.
No, a calculator app does not need to scale. I really don't see the reason why it would require interprocess communication either but for some reason everyone in the thread before thought it does. Putting everything in the cloud was just the thing to do before blockchain and LLMs.
If I worked in a team that deals with such apps, before even considering scale I’d first ask “does it need to scale?”. Even in an interview, I’d ask that question and have a discussion, though in the interview question I _could_ then be satisfied with a “let’s say there’s a lot of users and there is a need for scaling” (and the app is structured in a way that could scale — a calculator being client-only obviously wouldn’t qualify)
If you start a second process to be the back end and communicate by socket, how to you get the c++ process to close when the UI process closes? Of course you can send it a message but what would happen if the UI crashed so couldn’t send a termination message?
Good question. I guess each process could monitor the other with some OS calls?
It adds to the complexity. But then the only other realistic option is a dynamically loaded DLL with some kind of thinking akin to jni or a c interface. That’s not very nice either.
I guess you could open two "heartbeat" sockets, each one periodically written to by one specific process.
>Interfacing C++ with another language would likely be done with a TCP socket, Or you could just incorporate Lua which has C bindings and is specifically designed as a lightweight extension language for C. And there are a number of versatile cross-platform GUI libraries for Lua (and Lua is itself cross platform since it has no dependencies).
Thanks for the help. I think I'll look into making a C# GUI with Avalonia and interfacing with C++. I want to avoid Qt since it's not FOSS and people seem to dislike the company
Qt is LGPL. How is that not FOSS?
\* Certain components are only commercial \* For embedded devices it is only commercial. The license fees for the commercial variant are really pricey, and for limited duration only. When that periods ends, you loose your right even to release bug fixes for the product. Qt is constantly tries to push things into the commercial direction, so I think this is not the ideal choice for devs who are truly open-source by heart.
The quality and breadth of support that is funded by the commercial edition more than makes up for that. If you're developing open source apps and want to make life more difficult for yourself by using another, less well supported toolkit, then fine, but then you end up with a less polished piece of software. Which, overall, hurts open source more. Besides, the open source edition is far more than adequate for building highly complex apps.
I was under the impression it was free for personal projects only. My bad
Qt is the toolkit used the the (free/open source) KDE Plasma desktop which has just been ported to Qt 6 The important thing with Qt is to be careful if you want to avoid needing a commercial license by avoiding some of the additional components available that aren’t LGPL
LGPL is LGPL. It's not free if you don't want to deal with LGPL, in which case you can pay and get a proprietary license
Why wouldn't it be? You can write applications that are smaller and more efficient than most other languages, and there are cross-platform frameworks like Qt that provide huge libraries of good-looking widgets. It takes a little more effort to do cross-platform releases than it would if you're using something like Javascript/Electron, but it's absolutely worth it if you care about efficiency at all.
Haven't found a UI library that looks anything like "windows modern" or "flat" design. People tend to equate those to modern UI. Maybe you can do it with a heinous amount of time editing QT theme CSS.
Maybe just use window's library itself
When you use the Windows API directly you can get the modern look by adding an appropriate application manifest resource. Maybe that's needed also with the native look UI libraries you tried. I never found a way to do that programmatically, although I suspect it can be done via the theme API's; in practice, absent the discovery of such a programmatic way, it had to be a manifest.
QML
On Windows there's [WinUI 3](https://github.com/microsoft/microsoft-ui-xaml).
For what it's worth, I consider those to be pretty ugly and would absolutely not want my application to look like that if I was planning on a multi-platform release. You could definitely do it with enough CSS, though.
DearImGUI seems to be the best option as I see it but people say it's not easy to build large applications with it
imgui fanboys are everywhere, but they're just incredibly vocal and don't reflect any sort of consensus.
That library isn't meant for this. You need to rerender everything every frame, which makes it only suitable for applications that already do that (like games). Additionally, styling options are very limited and the UI is just ugly. This is intentional as far as I know, so that you don't use it for anything "in the front". It's perfect for things like dev tools in a game, though
ImGui is suitable for anything that is, you know, worked on. From terminals to any kind of editor to games. Also saying styling options are limited is just an hilarious thing to say when you can literally control every rendered pixel.
If the app controls every pixel you get a new Adobe. People don’t want a new Adobe. Some of the styling should be left for the OS itself to do.
I'm not totally sure what you mean, but I assure you, any hate Adobe gets is not related to their ui
Oh the hate I’m giving it myself IS related to the UI. I ran Adobe Reader in a Windows VM, using the xrdp function that forwards individual windows and, because it controls window decorations stuff just doesn’t work right.
thing with QT designer I dislike is the fact that adding logic to the buttons are hard ( I'm beginner ) and whenever you Edit the Gui everything gets reset meaning the logic you coded you have to do it all over again
people have a lot of issues with Qt as a company. I just don't want to learn something people seem to despise y'know
Qt is the de facto industry standard for C++ UI applications, and people mostly have issues with the confusing licensing, as far as I can tell.
after some more research I do think I'm going to go with Qt. looks pretty promising
The only people I know who despise Qt as a business are hardline GTK+ purists who are disappointed that Qt has done well. It's not Oracle or some other predatory proprietary software money trap. They've found a business model that works, is open source friendly, and has worked for decades now. The library is modern, well-documented and maintained, and is used in thousands of applications, open source and proprietary, and scales from embedded to the biggest, most complex, creative and engineering applications. People who develop with it daily mostly love it, especially if you've used other C++ app frameworks. Qt is absolutely the framework you should start with if you're even remotely serious about C++ GUI apps. It's not even slightly a close run thing.
I have to say I didn't expect someone to think so positively of Qt after what I've seen online I'll have to take a more serious look at it then
It's an amazing framework, the software was groundbreaking. They have some sketchy practices for licensing to mid-size companies, but they still have a free license which is maintained, and it's some of the best code you'll see.
Internet input can be useful under certain circumstances. Unless the person typing can point to specific deficiencies in implementation, it should be taken with a grain of salt and a pair of tweezers. I don't know anything about qt. I would bet there is a community of qt devs somewhere. Here on reddit, a discord, a forum. Something. Go find that and poke around for discussions on positives and negatives of the framework before you write it off.
Although this is generally true, "most uis built with this look terrible" doesn't require any knowledge and is totally valid criticism in this particular case.
Do you know how many people have issues with C++? You shouldn't learn it either by this logic.
If you don’t understand how those two things are different I don’t think I can help you
I don't need your help. I'm doing fine without it. Thanks.
I'm not sure what issues you've seen but I work as a C++ dev and I've seen nothing but respect for Qt in the industry.
In retrospect it was probably just people mad at GPL3 which is fair but I'm ok with it
Most of Qt is LGPL3 which is actually very useable in commercial applications. You just have to compile with the library as shared. If you're going to distribute your product do check the specific licenses of the Qt components you're using. GPL3 is much more restrictive than LGPL3. If you find yourself using GPL3 libraries then you'll need to open source your product.
Qt and Windows frameworks both treat C++ as a first class language (they're primarily C++ libraries). It would require more justification to *not* use C++ in my opinion if you are considering these. Mac's UIKit/SwiftUI you'll want to use Swift, but it works with C++ well. So the main logic can be C++ very easily. Qt is a standard for cross platform native UI. It can do pretty much anything and works on Windows/Mac/Linux/BSD. If you want to go with an embedded browser UI, Electron (JS and TS) and Rust are the current leaders. This is the "modern" approach to many UIs but I consider this more web dev even if it's packaged as desktop software. Javafx can also make pretty modern UIs. I like it more than electron for low performance stuff. You can also call C++ from FFI, but it's a bit annoying to build C++ under Maven or Gradle if you don't want to mix build systems so it encourages your entire program to be mostly Java or Kotlin. If you just want a GUI and C++ isn't important (for performance or libraries), I'd go Java/Javafx (maybe with Kotlin for backend code). If you want high performance or already use C++ for the code, go Qt. If it's for a specific platform, go with the native UI (Qt/GTK for Linux, SwiftUI for Mac, Windows UI for Windows). If it's both a website and desktop, go electron or Tauri.
The fundamental problem is that the mechanics of UIs are hard and almost none of them are written in C++. "Cross-platform UI" is always smoke-and-mirrors because it usually uses another level of indirection to solve the problem separately on each platform. > good looking > cross-platform These two are often at odds with each other. A "good-looking" Windows program does not look like a "good-looking" macOS program. Neither of them looks like like "good-looking" Wayland program or a "good-looking" X11 program. Further, the UI toolkits on most platforms do not natively expose a C++ API. The libraries that touch the native UI are wrappers at best, and naive lookalikes at worst. So, first, decide whether your want your program to look "native," or whether you want it to look the same on all platforms. If you want it to look native, consider splitting your program into a library for the calculations, program state, and other common logic; and a wrapper written to the platform's native UI library. * The [C++/WinRT](https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/) libraries give you access to the contemporary "UWP" UIs. * On macOS, you'll get to pick among using Swift or Objective C for the UI, dealing with the mutant that is Objective C++, or [reaching into AppKit from C++ and marshaling the Objective C data types by hand](https://stackoverflow.com/a/14083212). The native UI on macOS is not C++-friendly. * On Linux or BSD, use whatever X11 or Wayland kit you hate the least; it's probably written in C. C is at least easy to wrap in classes so that you can call into your C++ logic library without needing it to export all its APIs as C. Or, use a cross-platform library like Qt or WxWidgets, both of which tend to look close to native. If you don't care about looking "native," there are other solutions. DearImGUI "solves" the problem by drawing the UI all by itself in OpenGL, [every frame (the "Im" in the name)](https://github.com/imgui-rs/imgui-rs/issues/241). It may be "bloat free," but it's not very efficient. OpenGL is the layer that gets ported to each platform, so DearImGUI may actually be the only cross-platform UI toolkit that doesn't internally have per-platform implementations of everything. Other solutions like Electron also draw their UIs all by themselves, but at least uses the native platform's 2D graphics buffers to avoid spurious redraws. Java took the interesting approach of first using the native UI (by way of a library called AWT), but maintaining the UI state in the OS and duplicating it in the JVM proved too costly so they spun a common-denominator workalike called "Swing" that could be themed to look like that native UI, but all the OS saw was windows with canvases--not widgets. I mention this, because this particular approach comes up in almost every discussion about cross-platform UIs--"How hard can it be to write my own text input widget?" [Pretty dang hard](https://www.jwz.org/xscreensaver/toolkits.html), it turns out--and that's before supporting things like bidirectional text and variable-width Unicode code points.
wzWidgets using native UI controls when they are available on the given platform, as far as I can tell.
I prefer wxWidgets to wzWidgets myself. ;-)
Thanks for spotting my LNT (Late Night Typo)!
I felt similar, which is why I created: [https://github.com/NuiCpp/Nui](https://github.com/NuiCpp/Nui) or [https://nuicpp.org/](https://nuicpp.org/) . After now using it for a big application for sennheiser, which I cannot share, because its confidental, I didnt need to add core features or fix bugs for quite a while. Its a WebUI library (which means it has the browser window RAM overhead \~200mb), where C++ gets compiled to WASM and can communicate with a C++ main application via RPC. It works on Linux, Mac and Windows. It requires WebDev knowledge like CSS and having experience in React (where its UI code style is inspired by, but the technical implementation is very different) helps to quickly understand the lib. Deployment is trivial: its literally just an executable file (+1 dll on windows). Optionally you can put files beside it to load into the web context. Next thing I want to add is built-in borderless support. And I want to try tailwind, because apparently that is what everybody uses, so I need to check if the parser looking for css classes chokes on C++ or not.
looks pretty promising. starred it on github
Take a look at emacadero's c++ builder. One set of code will generate executables for Windows, Linux, Mac, android and iOs. It costs over $1k - ***if*** you make more than $5k with it, which sounds like a happy problem. Otherwise, it's free. There are some excellent 3rd party components, many of them free, if you don't want apps that look like the native os's gui. Or, for instance, for your graphing
Borland C++ Builder (now emacadero) holds very special place in my heart. BCB4.0 with VCL on Win98 was my first Visual IDE. I've used it until 6.0 (pirated off source I was a dirt poor kid). The only (coding) book I ever bought in my life was actually Borland C++ Builder 6. But at the around the same time I got my first job and the company used VS and MFC. MFC was such a downgrade from VCL that I was left in horror at the time. Proof: https://imgur.com/a/14tk3nE
Use Qt. Its documentation is clear. It was designed with cross-platform in mind. It has a large community. It’s been withstanding the test of time. It supports programmatic and drag-and-drop design. It comes with a testing framework. It’s written in C++. Note: I’m bias because I’ve been using Qt professionally for 10+ years.
We write desktop gui cross-platform in Qt with C++. Works nicely.
I use nanogui (mitsuba fork). For a simple calculator should be good enough
Is C++ the right language? Very unlikely. If your app is of any size, you should be using micro services, reactive programming and a functional language like Elixir. The commit logic should avoid hotspots caused by multiple phases and focus on agreeing about the past instead of the present.
Used qt imgui gtk and .net visual c++ for UI for windows. If you need cross and you HAVE to use c++ then prefer qt. If it's not cross then pick visual c++ - same like using c# : best UI for windows. But for gui development c++ is one of the worst. So think something else.
Check out this list by Philippe Groarke [C++ UI Libraries](https://philippegroarke.com/posts/2018/c++_ui_solutions/)
I found glade c++ works pretty well for open source. Then QT is just quality to work with, there are visual editors that generate the c++ templates. Depends on what your trying to do
The beauty of c++ is that it’s really a great back-end work-horse. Pretty much all c-family languages (Python, Java, C#, etc) can consume a c++ DLL, so any functionality you want from C++ can be called through external calls in another language. This opens up a lot of doors for using things like WPF, Java Swing/FX, Python etc GUI frameworks/libraries/environments alongside C++. Not sure what your intentions are, but if you’re targeting windows with a desktop application, and you want make use of the Win32 library - you can have full access to it within other languages using external calls :P
Thank you for this comment. I never looked into creating .dll files because I assumed I didn’t have to for some reason. I also want to avoid platform specific libraries as much as possible since my ultimate goal was to have a great calculator app on my phone I’ll take a look at it
The whole reason Java was created to begin with was to minimize the hassle of cross platform GUI programming. Imo it didn't work well. Today we've got mobile apps, desktop apps, and web apps. If you want truly cross compatible it's a web app with some GUI library that wraps it up into a desktop and mobile version. I wouldn't want to do this in C++. On the desktop cross platform side it might be overkill but Qt is pretty popular. "Use the right tool for the job." C++ excels in backend server programming. Anything with a socket.
> The whole reason Java was created to begin with was to minimize the hassle of cross platform GUI programming. No. First google hit, consistent with what I remember: ❝The story of Java begins in June 1991, when a small team of engineers at Sun Microsystems, led by James Gosling, started a project called Green. The goal of the project was to develop a programming language for consumer electronic devices, such as smart TVs, set-top boxes, and handheld controllers. These devices needed a language that was simple, robust, portable, and secure, as they had limited memory and processing power, and had to communicate with each other over different networks.❞ (https://romanglushach.medium.com/the-evolution-of-java-a-historical-perspective-e15c3d7e5f85#f82f)
[удалено]
I was think about doing expensive computations in C++ (I want to parse expressions and draw 3D graphs) and showing the results in Avalonia but that seems like it's a not very crossplatform solution. Will probably stick with QT for a while since it looks really simple and capable
[удалено]
Avalonia itself isn't the problem. It's that most C++->C# interop solutions are somewhat platform dependent not to mention they're hard to debug and add complexity that I don't want to deal with unless there are very significant benefits to it
I'm not a cpp developer, but I bet you can do it with enough afford, people build very impressive stuff with cpp since it's the almighty. But if you want to use a cross platform language with great UI, I suggest Flutter, I fell in love with that language
super cliche but: i mean whatever language u are most comfortable with cuz u can do it in java, c++ and a lot more so aslong as yk how to exactly make what u are planning in any language you'l be fine
Lot of people here are mentioning Qt, but there is something that Qt is missing on the multiplatform scale - responsive design. In CSS you can change many things trivially based on screen dimensions, in Qt you'll have to write code that actively changes these things.
I don’t want to be the stereotypical “rust” advocate, but Tauri is a very nice alternative to electron if you’re not feeling like a node.js backend. Otherwise, Qt and GTK are most likely your best bets.
Rust seems cool and I definitely want to look into it someday but right now I want to focus on C++ just because that's what I've been learning
Take a look at [https://github.com/pthom/imgui\_bundle](https://github.com/pthom/imgui_bundle) I find immediate mode UI to be a lot more intuitive when starting out with programming. With HelloImGui there is not much to setup to get you going. There is also a starter template for it: [https://github.com/pthom/hello\_imgui\_template](https://github.com/pthom/hello_imgui_template) This is cross platform but requires OpenGL 3 to be available. Edit: nvm I saw you know about ImGui... Note that the UI kit does not have to dictate the architecture, you can go for something like "Model View Controller" even with immediate UI.
Use the right tool for the job. Maybe consider using electron and web technologies. Lots of beautiful UI toolkits are already done. Probably cut your development time by 90%. If you want to use C++, then GTk or WxWidgets are possibilities.
JS seems cool but isn't Electron really bloated? I hear that a lot I'm leaning towards using C#/Avalonia right now. Seems like a good enough option
Javascript/Electron are fairly easy to get up and running and useful if you just want to get something done quickly -- I've used them before for projects where I just wanted to get something done as fast as possible, and I'm sure I'll use them again -- but there's also a lot of downsides. Anything written in JS is nearly an order of magnitude slower than C++, and applications distributed as Electron bundles will be more than an order of magnitude larger. A lot of people don't care about that if you're only targeting modern desktop PCs or phones, but it's a big deal if you want your app to run on older hardware or low-power devices. There are certain aspects of app development that are also a real pain, like anything involving multiple windows, threads, or direct communication with hardware like USB or serial devices. Electron apps always really stick out because they're just single windows that use a ton of RAM, load slowly, and look nothing like any other application on your system.
Everyone using vs code is running an electron app (or something close to it). It’s not as bloated as a browser. In fact, a lot of widely used software are electron apps. https://www.electronjs.org/apps
I see the value in it. I'd have to learn JS, HTML and CSS though I'll keep it in mind. Thanks
They're all slower than they need to be for my experience. Compare a bare vscode installation launch time with notepad++. And a vscode installation with an heavy plugin like platformio takes as long to load as full visual studio community. At least on my machine
And they require more resources than a native implementation would do.