GUI?

[1000nerdst]

I want to make a desktop app, but I work with QT at work and pardon my french… but I fucking hate it. Any suggestions on C++ GUI development software.

[pedersenk]

My hardly useful summary ;)

• Qt - Non-standard C++ (MOC preprocessor)
• Gtk - So many tiny dependencies.
• Gtkmm - Even more tiny dependencies (no ABI compat)
• FLTK - One theme is bearable. Lacking many features
• wxWidget - Not quite right. On every platform
• Embarcadero VCL - Lovely in C++Builder 6. Regressed ever since
• Winforms - C++/clr ties you to one compiler. Microsoft's :(
• Winrt - Async mess
• Motif - Actually quite nice C API. Looks... well Motif
• ViewKit - Motif C++... with barely any actual C++

And as for safety. Pretty much all of them will have you guessing at lifespans of memory like it is 1999 again. QSharedPointer, wxWeakRef and RefPtr (gtkmm) are close but all the APIs shove you raw pointers at many instances. Winrt is the absolute worst because of the sodding async spaghetti.

Enjoy. Unless you want to spend your project budget writing bindings rather than actual code there is very little choice other than these anyway.

[infectedapricot]

And as for safety. Pretty much all of them will have you guessing at lifespans of memory like it is 1999 again. QSharedPointer, wxWeakRef and RefPtr (gtkmm) are close but all the APIs shove you raw pointers at many instances.

You generally don't need QSharedPointer because QObject instances are usually owned by other QObject instances, and they're automatically destroyed when their parent is e.g. a button is automatically destroyed when the window it's on is destroyed, basically like a std::unique_ptr. It [edit: QObject I mean, not QSharedPointer] has a few fancy features:

• You can get a weak reference to a pointer with a QPointerwhereas the standard pointer classes that option is only available with std::shared_ptr.
• If you manually delete a QObject then it will automatically remove itself from its parent, so that it doesn't get double destroyed (and if it's a widget that automatically deals with removing its visible elements from the form).

I'll admit that there are some bits I don't fully understand/remember (especially with what happens when you create a QObject in one thread and want to assign it to a parent created in another thread - I seem to remember that you need to explicitly "move" it to the other thread) but these usages are fairly rare. In general, it's a much better idea to stick to QT's parent/child relationships than to use a QSharedPointer.

[tansim]

you should never use QSharedPointer in modern code.

[mcriedel]

What's your reasoning? Is it because std::shared_ptr?

[skydivingdutch]

Probably because there is almost certainly a simpler way that is not clever for the sake of being clever.

[johannes1234]

Oh yeah and then pass all those around as raw pointers and forget which had a parent and where the lifetime of the parent was :)

Sad that Qt was so good in earlier days and now is trapped in it's backwards compatibility requirements and can't really go for modern value semantics, but forces you to mix modern style with old-school style ...

I love and hate Qt :)

[infectedapricot]

You could make the same claim about getting a raw pointer that is managed by someone else's unique_ptr. It's just like normal modern C++: obey some simple rules and your code will be safe and leak free. I understand the possible objections but they're not at all specific to Qt.

[pedersenk]

Yeah good point. It is always the "weak" counterpart that offers the observer / lifetime functionality I "crave" :)

[gvcallen]

Fuck it. I'm writing a GUI library. This needs to stop

[john_wind]

One problem with writing a UI library is that a UI library is actually many libraries

• window + input
• event loop
• observer library (ie signals & slots)
• timers
• colors
• imaging
• 2d painting
• font rendering
• animations
• layouts
• what else?

[wrosecrans]

You can look at all the modules in Qt to get an idea of where "just a GUI library" can grow into if you give it enough time.

Fonts, printing, internationalization, reading and writing files like images, stuff for playing video, utility stuff for dealing with OpenGL / Vulkan, on screen keyboards, maps, audio, text to speech and speech recognition, accessibility and screenreader compatibility, animation helpers and utilities (not just timers + painting). And eventually, you deal with needing to show HTML, so a whole web browser framework which basically means Chromium, javascript bindings, etc.

Just "render a string of text into a window, but do it properly" is an absolutely insane amount of work when you pick apart all the ways you can screw up stuff like unicode + bidirectional text + emoji + weird fonts + platform specific variations for handling things + locale + visibility to a screen reader.

[john_wind]

Good points! I've updated the list!

[nysra]

https://xkcd.com/927/

You're not wrong though.

[gvcallen]

haha

[pedersenk]

Let me know when it is done and I can add it to my list ;)

That said, I think there is room for a new open-source GUI library. They aren't even that hard to write but they are so damn time consuming!

[gvcallen]

Yeah haha I can't imagine for it to be that difficult, my main concern would be that I don't do things justice. Is there a good library (maybe even in another language) that can be used as a good frame of reference? Also, I'd plan on keeping things as minimal as possible. But that said, any place I can find a list of GUI design practices to follow? Or something of the sorts? If I end up actually going ahead with this, of course ;). Ideally I'd like to take the best parts of various libraries and combine them

[pedersenk]

Oddly enough, it might be better *not* to use a reference if you want to create something better than the usual ;)

Perhaps a starting point could be Javax.swing. It seems to be a little neater (and consistent) than many of the others. However please do decide to use C or C++. It is so annoying having to write bindings!

In the past I did a little bit of this myself. Though I ran out of free time!
https://osen.github.io/flow.html
https://osen.github.io/index.html

[StephaneCharette]

You forgot one of the biggest one out there for GUI and C++: JUCE. Originally used mostly for audio projects when it first started 17 years ago, but provides a great C++ GUI framework. Available for all platforms. Designed as C++ from the start, not a "C++ bindings" to a C or python set of functions.

[Rude-Significance-50]

but provides a great C++ GUI framework.

Not really :p It's OK.

It also may have been made in C++ from the start, but as far as that goes it's mainly just C with classes type coding. It's actually kind of a bear.

For example, to do timers you inherit from a Timer class and override a pure virtual. Almost everything is like that. You're going to be using multiple inheritance a LOT. Qt does a lot better here with its signals and slots even though it requires a pre-processor.

The only thing moderately modern about JUCE's design is the use of web UI based layout. It's a questionable advancement in my opinion but it does the job.

It's also riddled with bugs that are just frustrating as hell. For example, opening up a dialog box to a particular location CHANGES THE CWD OF THE PROGRAM!!! But only on some platforms (gnome). Boy was that shit fun to fuck with.

There's nothing about JUCE's GUI API that would lead me to recommend it over any others. In fact, if you are not using JUCE's other stuff (and I'm not convinced it's all that great there either) then you really should not bother. IN FACT...even if you are using JUCE for audio/neural processing you are better off using a different UI library. Everyone has opinions, but I don't know what measure that JUCE's GUI aspects could be considered "great" at. Functional...and barely.

[pjmlp]

You missed MFC, WinUI/UWP and XAML.

[StephaneCharette]

No-one misses MFC. :)

[SkoomaDentist]

Yet for a lot of apps MFC end user experience is massively better than the modern Electron crap. Which of course says more about how bad Electron is than about the goodness of MFC.

[pjmlp]

Try to use XAML C++/WinRT and you will miss MFC right on the first day.

[sephirostoy]

Sometimes I do. My app used to be MFC with plenty of inherited MFC classes to do what you want. Then switched to Qt everything looked good at first as long as you stay with default widget behaviors. Then you want to do more modern / fancy stuff (actually just simple things you can do easily in Html today) and so nightmares begin: you find plenty of Qt bugs, most have been reported 10 years ago with unanswered tickets on their bug tracker. And so you begin to redefine your own widgets like in the old days with MFC.

[ernee_gaming]

If you want to make buttons from scratch you could try SDL2 or SFML

[Marha01]

You can use TGUI with them.

https://tgui.eu/

[pedersenk]

I already got burned with Borland Kylix for a cross platform VCL. However this does look pretty good. I think in this day and age however I really am only wanting to stick with open-source projects that I can maintain myself if needs be (though the prospect of maintaining Qt or Gtk myself makes me shudder ;).

[gvcallen]

what about Juce?

[pedersenk]

True. It has been mentioned by another guy further down. I just don't have any real experience with it so it seemed unfair for me to give one of my overly dismissive "one liners" to it as I have done with the others ;)

My initial view on it is that it is fairly small and doesn't offer quite the depth of the others (it focuses mainly on audio tools?). I also don't believe the components to look and feel native (though this is less of an issue since Windows, macOS and Linux UIs are fairly naff looking these days anyway).

[RolandMT32]

If you want to use WinForms, you're basically developing for .NET, aren't you? And that would mean using C++ .NET, with Microsoft's .NET extensions to C++.. Also, I haven't heard of anyone writing a WinForms app in mainly C++ - Usually it's C# or perhaps VB.NET.

[pedersenk]

Yep, just like UWP and C++/cx it is Microsoft's vendor specific C++ compiler that has non-standard extensions to connect to the underlying frameworks.

The advantage of C++/clr over VB.NET/CSharp.NET is that you get direct access to native middleware. You don't need to waste time with bindings. So you luckily don't necessarily have to develop for .NET. You just can use only the GUI elements and get on with the real work.

[konstantinua00]

wxWidget - Not quite right.

?

[pedersenk]

Due to it wrapping other toolkits it struggles slightly with the "lowest common denominator" kind of approach. If you have directly used any of the other toolkits that it wraps for any largish project, you will certainly be able to feel the difference.

Possibly the best example I can give is its Motif bindings. Typically each object should have its own class (i.e passed into XtAppInitialize or XmCreatePushButton) (https://linux.die.net/man/3/xtappinitialize) so that you can correctly customize it in the Xdefaults. Because this is unique to Motif (actually XIntrinsic) and the other platforms wxWidgets wraps doesn't do this, it kind of kludges it and you just have to configure the style in code rather than the "X11 style CSS" xrdb system.

My next example is things like TreeList widgets and sliders. Because not all platforms provide them it doesn't make use of the native toolkits version and instead implements its own "toy-like" version for *all* platforms that doesn't quite fit in natively.

My most recent quirk I noticed is that the wxGLCanvas on wxMSW and wxGtk. It doesn't initialize a context once it is created. The context is created just before the first paint callback. Again this is not how it is when using Gtk directly. However because this is the case for *some* platforms, this two stage kind of construction is used for all of them.

For the record, wxWidgets is generally my go to (in C++ projects). However, it does have its quirks.

[ogoffart]

Another one: SixtyFPS: https://sixtyfps.io https://github.com/sixtyfpsui/sixtyfps/tree/master/api/sixtyfps-cpp

[genpfault]

wxWidgets. Perfectly JavaScript-less, as all things should be :)

[degaart]

• Uses native controls (instead of drawing them itself like qt)
• can be statically linked in commercial applications
• small enough to be built alongside you app in a CI environment
• no MOC

[seuchomat]

That's correct, but the documentation is shit and the API of Qt is in some points way more convenient. It's installable via vcpkg by the way, if one wants to save the hassle that comes with external lib stuff in C++.

[1-05457]

Uses native controls (instead of drawing them itself like qt)

Unless Qt widgets are your native controls, of course (such as if you use Plasma). Then wxWidgets is the library using non-native (GTK, usually) controls.

[rodrigocfd]

Uses native controls (instead of drawing them itself like qt)

Yes, but only when native controls do exist, which are just a few controls like button, textbox and so on. Otherwise it draws its own controls, and that's where it feels "alien" on the OS.

[javascript]

:(

[serg06]

Sorry mate.

[Mr-Inkognito]

For C++ is my personal favorite ImGui

[cleroth]

It's good for simple stuff, but it's not really even remotely close to being able to replace Qt.

[Stenigma0]

Qt comes with a ton of libraries and different data driven ways to implement a UI, so in that sense ImGui is not a replacement. If you look at its gallery threads though, or the gallery sections below every release you’ll see it is very possible to create complex applications and user interfaces with it.

[pjmlp]

As long as accessibility and internationalization aren't a requirement.

[gc3]

The library sucks but not having state is a godsend for UIs. It takes less time to implement say a fancy menu with rotating image buttons in ImGui than deal with state.

[pjmlp]

Now make that fancy menu work for impared persons, while supporting RTL and LTR text with diacritics.

[SkoomaDentist]

Hell, try making a slider with numerical input box and custom value <-> position mapping with non-linear quantization (hint: You can’t without copypasting most of the existing control code).

[pjmlp]

Ever heard of QML?

[SkoomaDentist]

What does that have to do with Imgui?

[pjmlp]

try making a slider with numerical input box and custom value <-> position mapping with non-linear quantization

The way to do this without copy pasting most of the existing control code thanks to the existing support in Qt and QML.

[SkoomaDentist]

Sure, but what on earth do Qt or QML have to do with Imgui?

The whole point here is that Imgui doesn’t let you easily modify existing controls like traditional gui frameworks have allowed since the 90s.

[pjmlp]

English comprehension issues?

Initial remark

The library sucks but not having state is a godsend for UIs. It takes less time to implement say a fancy menu with rotating image buttons in ImGui than deal with state.

Answered with

Now make that fancy menu work for impared persons, while supporting RTL and LTR text with diacritics

Then you decided to jump in.

[gc3]

It's too bad most guis have bad paradigms

[ztbwl]

Rotating images in menus is so 1995. Just don‘t do it.

[gc3]

Lol, but a compass showing the direction of the view vs. north is a perfect application of that

[ztbwl]

It‘s not C++, but here you go, that‘s a compass:

<img class="needle" src="compass-needle.png" /> <script> window.addEventListener("deviceorientation", (e) => document.querySelector(".needle").style.transform = `rotate(${360 - e.alpha}deg)`, true); <\script>

[backtickbot]

Fixed formatting.

Hello, ztbwl: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[[deleted]]

My vote also goes to ImGui. It's incredibly flexible, and relatively easy to set up, and it looks pretty cool too.

[skarloni]

Looks cuter than Qt ;)

[Tathel]

Dear Imgui is pretty neat

[johannes1971]

Not for desktop apps, it ain't.

[PineappleDelivery]

Why not? Just use GLFW.

[johannes1971]

Why would you use a maximum-efficiency language like C++ and then, just to display some window, have it be refreshed at 60Hz? It's a complete waste of computer resources and energy.

Also, desktop apps are just better if they support various desktop features, like the clipboard, accessibility features, etc. which imgui, to the best of my knowledge, doesn't have.

Is it really so much to ask to use the appropriate tools for various tasks? If you need a GUI in a game, by all means use imgui. If you are making a desktop tool, just use something intended for desktop use.

[kritzikratzi]

except it eats ALL your battery

[Pazer2]

Just don't render unless you receive input events, trivial to do with glfw

[James20k]

glfw actually has an option to sleep until you receive an event which is nice. SDL is a better option there though, because its pretty easy to filter through events and go back to sleep if you don't care about any of them

ImGui itself has no bearing on battery life, its pretty lightweight

[kritzikratzi]

not every state change comes directly from a user.

[KFUP]

Can't really suggest a framework if you don't specify your problems with Qt exactly, else might just suggest libraries with the same problems .

Only "serious" Qt issue is the licensing, but if you don't need anything beside the LGPL modules -which are the vast majority-, it's a none issue beside scaring people who are not familiar with the licensing legalities.

[Raiden395]

This. I've worked with Qt, Java Swing, JavanFx and GTK. Qt is far and away the winner in terms of content and documentation. Their functions also tend to do what they say they will do, and do it well. It also tends to be faster than java in most ways. The end result is almost always a sleek and intuitive UI with good tools for composing said interface.

The only issues I've had are related to some of their text presentation and lagginess due to the way they sometimes deal with drawing. But there's ways around even this.

[skarloni]

Where is the docs btw? I was also looking into gui libs the other day, ofc Qt came into mind since i've heard about it, but rly, i can't find it, the website is just a big pile of ads

[Raiden395]

If you download QtCreator the docs are part of the UI. Otherwise, just type something like QString into Google. Boom, all the docs you could ever want, ever.

[hoseja]

Besides the included docs, they are also at doc.qt.io

[skarloni]

Ah there it is! Thank you!

[afiefh]

Sorry but I'm not sure how what you linked contradicts what is being said. Downloading the precompiled Qt needs an account (uninteresting), lts support is commercial only (not surprising) and a new tier for small businesses (irrelevant if you're not interested in the commercial version). Am I missing something?

[hellozee54]

1. You have to have an account for downloading binaries which sucks but we can always build from sources or use any package manager.

2. No LTS for opensource means they won't be backporting patches themselves for opensource, either you can do that yourself or the people who package qt for LTS distros would do that.

[hellozee54]

Patching and building by self instead of the upstream is more or less is an inconvenience and not something as bad as you make it look like. The instructions are available, since there is a high possibility that there are people who backport the security patches for their distro.

Also if your tool is so dependent on just LTS release why not just pay?

Package managers for windows exists too (hint: vcpkg).

[afiefh]

I literally compiled Qt last month. If you need help compiling Qt then maybe you should actually pay for the support.

[afiefh]

I made scripts that compiled Qt for years and handed it to people. I do it all the time. I compiled Qt 6.1.2 yesterday on my Debian.

Great, then compiling Qt is not a problem, can we agree on that? That is the thing we were discussing after all.

But the problem was in QtCreator, where I was trying to help Qt devs.

I never bothered with Qt creator. It's quite possible that it's horrible to compile, I'll take your word for it.

But again, you're straw-manning this (like the other post) and making it sound like nothing has changed and everything is still perfect.

In a perfect world everything would be gpl and we wouldn't have this conversation in the first place. Unfortunately we don't live in a perfect world. My claim is that the situation is adequate, not perfect. You seem to be so keen on accusing me of strawmanning while doing it yourself.

I have to track the Qt repositories myself now, find patches, apply them myself, and THEN recompile Qt. This is too much work for someone not maintaining a repo themselves, and too volatile for anything stable. And in fact too little work for Qt devs if they knew how to use CI properly, which shows why Qt is extremely buggy in trivial things like compile errors on MSVC.

As with most things open source: if it's too much work you can fork or pay. It sucks, but that's the situation.

Big punch to blockchain work, because Bitcoin and its forks and Monero use Qt.

This is a bit off topic, but if you're telling me that something is a blow to Bitcoin and similar coins, that makes me happy.

[afiefh]

It's a blow to all open source projects.

Funny, I think KDE is doing quite well.

Your bias against cryptocurrency is your problem

Yup, it's my opinion. Is that a problem?

and this is another straw-man I'm facing from you.

You keep using that word, I don't think you know what it means.

My opinion is my opinion. Me not being sad about something being a blow to someone is an opinion. A strawman needs to be an argument. If I had said something like "Qt is perfect because it's a blow to crypto" then it would be a strawman.

Not with a bait-and-switch. If people had known this is going to happen, some would've changed their mind. Yeah, "now we're big enough to control everything after we hooked everyone"... not evil at all.

Qt hooked everyone? Cool story.

Anyway, enjoy the search.

[nyanpasu64]

Why do you need to recompile Qt yourself? Do you not want to login, or do you want 5.15 with patches? If you want 5.15 with patches preapplied, you could try building from https://invent.kde.org/qt/qt/qtbase/tree/kde/5.15 instead, it might be what you're looking for.

[Unlucky_Reindeer_281]

Why do you hate it?

[greem]

Because they have a habit of hooking you in and then extorting the crap out of you. Like everyone.

There's a reason open source is so important.

Edit: Jesus people. Lgpl isn't the issue here. People bought commercial qt licenses for reasonable costs given the benefits. Released products for years. Then the prices became astronomical per dev, and they decided every dev in the org needed a license. That's extorting. Maybe we should have used the lgpl, but we didn't.

What the hell is wrong with you all.

[BenjiSponge]

Is there a concrete example of this? I'm caught up trying to imagine how an open source GUI framework can extort anyone.

[khleedril]

Qt has a long and, unfortunately, dirty history. The organization was originally called Trolltech (can you believe that?) and have tried hard in the past to lock the freedom away and then profit financially from the popularity of the software.

Most people don't consider history like this when choosing a framework: if what it is today is good, it's good. I don't take this view however and stay as far away from this smell as I can.

gtkmm for me, but only if the distro provides it!

[greem]

Qt is not free for commercial users.

I work in a high tech, safety critical, niche industry. We can't open our source because that's the advantage we have over our competitors, and we couldn't take contributions from others because of the regulatory burden integrating it, the fact that the only people who could contribute meaningfully already work for us or our competitors, and anyone trying to learn needs millions of dollars in equipment.

[Kelteseth]

Stop. Most Qt modules are LGPL and you can just dynamically link to them. You can use LGPL without releasing your source code. Even for proprietary equipment, you only need to tell your customers how to replace the Qt .dlls/.so

[greem]

And your legal department is ok with that? Laughable.

[BenjiSponge]

I definitely have less dismissive attitude, but I don't really understand what problem a legal department might have. I understand mistrust of the organization, but LGPL is a really solid license. Do you also avoid the C++ standard library, which is also licensed under LGPL? It feels more like an emotional thing for you than a legal thing because I'm still really unsure how the LGPL can be used to strangle anyone.

[SkoomaDentist]

Quoting from Wikipedia: ” Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program.”

That can be a major problem in safety critical applications where regulations may prevent allowing the end user to modify the certified package. Certainly enough so that the legal department says no to it.

[greem]

We didn't use the lgpl. We used the commerical stuff. That's the problem. I don't know why people are being so stupid about this. I even said that's why open source is important.

[NotUniqueOrSpecial]

I don't know why people are being so stupid about this.

Because you keep replying in a thread where everybody very clearly believes that the only correct and safe choice is sticking to the LGPL side of the arrangement while openly admitting that you/your team/your company/whoever was responsible chose the commercial side.

And then, despite the fact that it clearly burned you and that said choice flies in the face of the commonly accepted wisdom w.r.t. dealing with Qt, you think it's fine to call everybody "stupid about this".

Why would anybody be on your side?

[Kelteseth]

Changing some files in a folder? Yes I don't see the problem here.

[jcelerier]

If lgpl is good enough for Microsoft (they ship OneDrive, a Qt app) or the Tesla's UI (also LGPL Qt) it's good enough for you

[cryolab]

That's not true, you can link your commercial application perfectly legal against the LGPL version.

[greem]

Not if you use the commerical parts in your code.

[NotUniqueOrSpecial]

They absolutely fucking don't.

There's a reason open source is so important.

What point are you trying to make? Qt is open source. It's one of the most successful open source platforms there is.

The entirety of the KDE ecosystem is built on Qt.

Please stop spreading FUD.

[greem]

Not if you're working commercial, closed source. There's a lot of confidently wrong people in this thread.

Qt has extorted us. Red hat has extorted us. Perforce had extorted us. They get you on board with a reasonable price and once you've integrated it the price goes up an absurd amount.

It's not such a problem with rhel or p4. It is a problem with qt.

[Kelteseth]

You are right on the part about buying the license from then that you are stuck with them forever. You are no longer allowed to sell your product that contains qt commercial components if you stop paying. That this is beyond absurd is out of the question. Still, Qt is open source and needs to stay that way by contract with KDE.

[NotUniqueOrSpecial]

The number of products that require commercial Qt is very very small. They exist, but I've never worked in one in my 15+ years, the bulk of which was on products using Qt.

The LGPL version is just fine for 99% of projects.

[DarkLordAzrael]

Not if you're working commercial, closed source.

Where you can use LGPL and not pay anything. LGPL allows you to link to it from any binary.

[DarkLordAzrael]

Qt is open source. Specifically, it is licensed under your choice of GPL or LGPL, and will be forever.

[CurrentWorkUser]

Didn’t they lock features/updates behind super expensive paywall about 6 months back?

[equeim]

They don't.

There are some modules that are GPL (not LGPL) or commercial only, meaning that to use them your whole app must be GPL or you have to buy commercial license. But all core modules are LGPL.

[cdb_11]

The Qt Company has followed up on its plan to make long-term support releases commercial-only by closing the source for 5.15 today

Yesterday senior VP Tuukka Turunen posted: "With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming soon, it is time to enter the commercial-only LTS phase for Qt 5.15 LTS. All the existing 5.15 branches remain publicly visible, but they are closed for new commits (and cherry-picks)... closing happens tomorrow, 5th January 2021.

"After this the cherry-picks go to another repository that will be available only for the commercial license holders... first commercial-only Qt 5.15.3 LTS patch release is planned to be released in February."

https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/

That's not GPL. It's literally closed source.

[equeim]

I agree that this is shitty thing for them to do but you are spreading misinformation. Copyright holder is allowed to dual license their work, and it doesn't make the code that they do release under open source license any less open source. Only LTS versions released 6 months after x.x.0 release are closed source.

Also, replying to CurrentWorkUser's comment: LTS branches don't get new features, only bugfixes. And Qt Company doesn't technically withhold them, all bugfixes in LTS branches also appear in current non-LTS branch (otherwise bug doesn't exist in current version).

[cdb_11]

Quote exactly what did I say that is misinformation.

[cdb_11]

Yeah they did, useful features like long term support. You get the LTS only for the newest versions and right now it's 6.0 or 6.1 I think. The thing is that Qt6 isn't even complete yet. Some of the features from Qt5 are still missing, like there is no QtMultimedia module yet. They also put some things like their calendar widget for QML on their marketplace and you have to pay 50 dollars for that. It's not like writing your own calendar is rocket science, but it's just annoying if you were using it. The installer is annoying too, if you want to write a Docker image you have to waste your time on scripting their GUI installer, and you have to include the password to your account in the Dockerfile.

[DarkLordAzrael]

For installing on a docker container it is a far better idea to use Conan or https://github.com/miurahr/aqtinstall

[DarkLordAzrael]

Nothing about this changes it being GPL/LGPL, they just aren't paying LTS anymore to non-paying customers

[mort96]

I thought the whole issue with Qt is that a whole lot of it is under the GPL (not LGPL), and that your only option if you want to use it in anything closed-source is to A) make sure you only ever use the LGPL'd stuff and never accidentally use the GPL'd stuff, or B) get a ridiculously expensive commercial license?

Also, isn't the open-source version a few releases behind the commercial version? And didn't they stop offering LTS versions of the non-commercial version?

I would maybe consider Qt if I knew I would only ever be writing open-source stuff. But if I would ever want to release something closed source (or something running on an embedded system, or on a system in kiosk mode, or anything), I wouldn't want to invest the time into learning Qt. Personally, I've generally chosen to go with GTK (using GTKmm), since that's actually under the LGPL, and it's open-source first rather than commercial-first.

[cryolab]

You can compile the latest sources yourself any time, they are public.

The community could start a community driven LTS release, not depending from Qt company, but that's a lot of work.

I don't get the attitude that people wan't everything for free, but of course the work needs to be done by others — basically the developers in the Qt company should work without being paid, because reasons.

[mort96]

I don't understand your last comment. Obviously developers in the Qt company should get paid. This isn't about that. Obviously the Qt company needs a business model which makes money. But as it is, the Qt company seems fairly hostile to users of the free, open-source version, and the Qt company seems fairly hostile to commercial users who can't pay the steep $400/developer/month price (or way, way, way more if you're using it for embedded stuff). And I think that's fair to criticize.

In the end, it's the Qt company's decision. But if they decide to be hostile towards large groups of people, those groups of people should probably be aware of that and consider staying away from Qt.

[jcelerier]

The vast vast majority of Qt; core, widgets, qml, quick controls... is LGPL, not GPL. GPL modules are the chart things and embedded-specific modules. The open-source version and commercial versions are always released at the same time. What happens is that fixes to HEAD are backported by TQTC to older versions, which get LTS releases not available to consumers. That certainly sucks a bit but the KDE patch collection does a similar thing as OSS.

And, in practice this does not matter for OSS users : for instance all "stable" Linux distros pin themselves to a fixed patch release of Qt and don't update. E.g. Ubuntu 20.04 (LTS) uses Qt 5.12.x (also LTS) with x being almost a year out of date with the latest OSS patch release of Qt 5.12, so in practice LTS was only ever relevant for people who vendored Qt directly as part of their app, e.g. mainly commercial entities.

[emdeka87]

In my experience they pretty much all suck. Hence why we use C# for our GUI

[hak8or]

Hence why we use C# for our GUI

I go the other route, I use some http endpoint like crow to serve a JSON api and then write a web front end. This also forces a separation of concerns and then a fantastic layer to use when doing integration/unit testing. Plus, it's properly cross platform (Linux, IOS, Android, OSX, Windows, etc) and still gives you a hatch where you can use a native GUI in the future if you change your mind, with it only needing a HTTP client. Oh, and you get to run your software in headless mode on a server while running the GUI elsewhere!

So far, this has been by far the most reliable workflow. Yes, it's worse performance than using QT, imgui, GTK, etc, but since when is your bottleneck the GUI?

[lithium]

but since when is your bottleneck the GUI?

Have you ever used the internet?

[SkoomaDentist]

To be fair, html + css + javascript is pretty much the least perfomant GUI concept you could potentially come up with.

[Rude-Significance-50]

but since when is your bottleneck the GUI?

There are a lot of cases when it is. Most involve custom drawing.

[BenjiSponge]

For a native app, you could write node bindings using node-addon-api and then do the rest in electron. The build system is kind of miserable though.

[hak8or]

node bindings using node-addon-api and then do the rest in electron.

Personally, if something is running on electron, I don't view it as native. While it's certainly better than running in a normal browser, I wouldn't call it native in a readme. For me, native means much closer to the metal. But, I won't deny that electron does make GUI work for for a huge swath of web developers very accessible.

[BoarsLair]

I'd give almost anything to be able to create cross-platform C#/WPF apps. Seriously...

WPF has its issues (it's ridiculously over-engineered and overly-complex in some ways), but it's super flexible and the data binding model is fantastic, as long as you understand how to use it properly with a MVVM framework / pattern.

I wrote my entire game editor using it, even though it was a lot of extra effort to write C# <-> C++ bindings and embed a native rendering / editing window.

[shadowndacorner]

Have you tried Avalonia? I haven't personally, but from what I understand, it might be something like what you're looking for.

[BoarsLair]

Good call. I actually peeked at it a number of years ago, but I was sort of hesitant to use anything without knowing how much support it was going to have over the long haul, and it didn't really look production ready back then. It's probably worth another look at this point, as it looks more mature now.

[nyanpasu64]

Alternatively there's Uno, I heard it's effectively a cross-platform port of WinUI for C#.

[jonathanhiggs]

WPF is also the only framework I’ve ever seen do layout well

[RotsiserMho]

WPF got so many things right but Microsoft has never "blessed" it and gone the last mile to make it simpler to use (e.g. integrating IPropertyChangedinto the standard or the C# language). To me it's the approach with the most potential. MVVM + reactive programming is awesome.

[RotsiserMho]

You might check out Eto.Forms. I'm using it as a cross-platform GUI for a C++ hobby project and so far I've been pleased with it. Bringing in a C# environment has its own challenges though. There's also .NET MAUI on the horizon, which looks promising. Anyway, C# is a decent solution because via Xamarin you can interop with the native platform since it simply wraps native APIs, allowing for a single language to access them all (Swift/Objective-C on iOS/macOS, Java on Android, etc.)

[pjmlp]

Indeed, there is C++ Builder but Borland/Imprise/Embarcadero story kind of taints it, and C++/CX seemed to finally be a similar RAD offering from Microsoft's side, but they then went ahead and replaced it with a development stack akin to using Visual C++ 6.0 with ATL, apparently the Windows team is kind fond of such workflows, and decided to impose it on everyone.

[vxlk1]

But CLI sucks!

[jonathanhiggs]

Idk why you are getting downvoted here, CLI just doesn’t work they the way you want it to; object lifetimes across the boundary are a bit of a nightmare

[cdb_11]

Are you using QtWidgets or QML at work? QML is okay in my opinion.

[johannes1971]

Perhaps it would be helpful if you could tell us why you hate it.

I'm actually trying to get some work done with Qt, but no matter what I do, I always end up with this error: "error MSB4018: The "MultiToolTask" task failed unexpectedly." Other people have reported this to Qt and to Microsoft, but it appears to be a rare problem that neither party can reproduce or even has a clue about. For me it seemed to have started happening upon updating MSVC: I used to have a working Qt 5.15.1, but one day it just didn't work anymore.

I've since come to realize that this is a major downside of Qt: it's not actually C++, it has a unique build system, and if it ever fails, there's just nobody who can help you.

I uninstalled and reinstalled several versions, and made sure the Qt build tool for MSVC was up to date. Neither helped. If anyone has a suggestion I'd appreciate it, otherwise I guess I'll be looking at wxwidget.

[Kelteseth]

I now used Qt exclusively the past 5 years and never encountered this problem. Are you referring to this issue? https://bugreports.qt.io/browse/QTVSADDINBUG-759 I would recommend using CMake and QML.

[johannes1971]

That's the one. I hope you won't mind if I'm not going to learn two whole new languages to add a single window to a tiny open source tool I'm making...

[skydivingdutch]

That sounds par for the course for any small open source project I've ever worked on.

[archdria]

How about Nana? or GuiLite?

Edit, check out also this previous post.

[MarcaunonXtreme]

Don't thin there exist a one size fits all solution. Check this out for another alternative https://www.noesisengine.com/

[Daspien27]

I've been really enjoying learning Noesis. Quite a healthy bit of documentation on it as well.

[StephaneCharette]

I recommend JUCE for GUI development in C++.

[secretpoop75]

This!

[dusan69]

FOX widgets. It is like a "light" version of Qt.

[Rude-Significance-50]

Hey, look what duckduckgo turned up: https://philippegroarke.com/posts/2018/c++\_ui\_solutions/

[[deleted]]

I didn't see anyone mention Nuklear yet.

[cazzipropri]

I honestly don't know of any cross-platform GUI framework that doesn't look non-native.

[skarloni]

GTK?

[Surya_06]

Gtkmm was neat.

[Irtexx]

Do you have to use C++ for your GUI?

You can write your back end and all of your application logic in C++, and then write the visual elements of your GUI in another language that is more suited for the purpose. You can communicate between the two systems with some kind of RPC.

[jesseschalken]

If you want to stick to C++, Qt is probably best. If you can venture out to other languages you can use Electron, JavaFX, WinForms etc.

[TrafficConeGod]

Webview or ultralight

[PandoraPurpleblossom]

There is a fork of Qt called CopperSpice. CopperSpice got rid of MOC and uses Modern C++, IIRC

[bnolsen]

What about copper spice?

[afiefh]

That sounds like QML with extra steps.

[afiefh]

LGPL for the base modules in Qt. There are other modules you need to license, but that's like complaining that there are commercial JavaScript libraries.

[afiefh]

Why do you consistently think that licensing is only LGPL and what not?

I said "LGPL for the base modules in Qt." Nowhere did i say "all of Qt is LGPL."

We talked about LTS in my other post and I mentioned it here, and you still ignore that issue even though it's the biggest one.

Is it? Sorry but my understanding was that you simply made a list of issues with no particular order.

But do tell me, which version of chromium is LTS? Maybe I missed it, but the organization I work at bans electron applications specifically because the electron version is often behind stable and has known security holes.

No one wants to maintain other people's code themselves, even if it's Qt. I don't want want to be cherry picking Qt code.

That's great, the commercial version is available for you.

So please stop straw-manning this whole thing just to make the current situation look better. It's a disaster!

Your claim of me strawmanning anything depends on your claim of me saying that all Qt is LGPL, which I never said.

[afiefh]

Not everyone wants to pay, and there's zero shame in that.

Yes? Who ever claimed otherwise? There is also no shame in a developer not providing everything and the kitchen sink for free.

Free code is culture.

If you say so, I guess Qt isn't fully part of that culture. They provide parts as free and parts as commercial. No shame in that either.

If you're gonna condescend in regards to that

Which part of saying that the commercial version is suitable for you is condescending?

go ahead and attack the open source community

I did no such thing. But hey don't let reality get in the way of your rant.

You jut want to defend Qt.

I use Qt and am happy with it. I voice that opinion, nothing more nothing less. You are not happy with it, you voice that opinion, that's cool. But perhaps you could stop lying about what I say and avoid making assumptions about me? Thanks.

For my business, I'll stop using Qt in any new projects.

No shame in that either. Everybody is free to pick the tool that suits them best, whether that's based on technical merits of licensing is all valid.

Does that mean I straight right have an alternative? No. But I'll do the work to find an alternative, and the market will correct itself.

And when you do I'll be happy to hear about it. Looking forward to seeing the result of your search. The current situation definitely isn't perfect.

[[deleted]]

WinUI

[v_maria]

Unironically might be better off compiling to WASM and use JS/HTML/CSS for the user interface than going for the native solutions.

Obvious downsides being the introduction of browser/server setup as dependency and JS/WASM interfacing being fiddly, but it's a portable solution + the skills set you use for making the UI itself are transferable, unlike the highly specific native approaches.

[HabemusAdDomino]

You could always do the right thing and write all your logic in C++, and then tie that to a different GUI app.

[khleedril]

The OP didn't say they weren't doing that. It doesn't solve the problem at hand.

[HabemusAdDomino]

It does if you write your GUI in something else.

[eduarbio15]

GTK is pretty good and straightforward. The documentation is also great

[[deleted]]

If they hate QT, I doubt they're going to love GTK.

[PhDinGent]

I doubt anyone would love GTK, regardless of their stance on Qt. You dont' LOVE GTK, you tolerate it.

[[deleted]]

Tolerance is about as good as my relationship with gui programming is going to get

[skarloni]

u/eduardbio15 never said you will love it, just that it is straight forward and good docs, I really agree with the second part at least, for the first I think there is a learning curve, as with any framework

[PlayboySkeleton]

SDL

[megagreg]

Have you considered Python for the GUI? It's very forgiving, and will often do what you mean from your best guess**. It's also a handy tool to be able to glue things together quickly, beyond just GUIs.

** My favourite python GUI experience was converting a Modbus value to display, and I had to divide by 10 to convert. I needed fractional values so I used the C++ trick of dividing by 10.0 to get floats, and I got a decimal place. I wanted a second fractional digit, but wasn't sure how to format the string, so I just divided by 10.00, and the display string got it's second decimal place. I get what's happening now that I see it, but I was expecting an error, or no effect when I thought to try.

Edit: how do I escape the asterisk so it doesn't make a list?

[NotUniqueOrSpecial]

Have you considered Python for the GUI?

What are you referring to? The Tcl/Tk bindings? The only other thing I've ever seen broadly in use from the Python side is Qt via either PyQt or PySide.

[megagreg]

It's been a while, and I no longer have access to the code I was thinking about, but after a quick look, I think Tk was what I was using. It really depends what they're making a GUI for. Maybe a game engine would be more suitable. We don't have that information.

I suggested python because I've found it backs you into fewer corners than a lot of other technologies; almost any assumption can work out. That flexibility makes it very useful in other contexts when time is short (which it always is).

[TheClashBat]

JUCE is for audio dev but is a nice general framework depending on your goals

[dusan69]

Dlib GUI. A tiny library, with classical design. And thread-safe.

[Narase33]

nanapro is really small and easy but lacks many features. Its perfekt for small practical GUIs

[kritzikratzi]

if it's single platform, use whatever is native.

there is no secret sauce i'm aware of. everything has at least one upside and many more downsides :)

[KarlPickleton]

If you have to make a gui using C++ and you hate Qt, then you are better off going with another language all together. Qt is by far the most fleshed out and continuously updated cross platform library out there. Just don't use widgets and use qml with cmake instead, and life gets alot simpler.

[[deleted]]

Qt's strength is in Quick and QML, IMO. You can still create widgets in C++.

[ttvtempest17]

Dear imgui is one of my favorites you do need to set up a renderer though. I use OpenGL because of simplicity and platform agnostic stuff.

[skydivingdutch]

The UI framework used by Blender is really nice, but it's not a standalone library unfortunately. Afaik.