Qt (and QML especially) is, in my opinion, the best way to do any modern-non-web UI work. Its built on a hardware accelerated scene-graph allowing for smooth compositing and animation, QML is an easy to use means of creating your UI and connecting it to C++ (especially post-C++11) is trivially easy allowing for good solid high performance UI's. You can also use Javascript if that's your thing, but for large applications (or iOS where its interpreted) you will need to take care to not run into performance issues. For small applications, its not a problem though.
Additionally, QWidgets, the old pure-C++ based UI libraries are still available too. It also bundles a ton of other stuff, an embeddable web browser, javascript engine, collections library, concurrency library, networking library etc.
I do agree, but only if we emphasize the cross-platform requirement and a single monolithic code base.
I’d much rather write a lightweight desktop app in any of the native toolkits, but especially Cocoa/Swift, and do the heavy lifting parts outside of the GUI application. But you’ll still have to write a native Linux one, and QT is my front runner there. But I do recommend looking at the Xamarin stuff too. Depends on your needs and where you’re coming from as a dev.
When you're stuck with C++, writing a GUI in anything but Qt on Windows or Linux is basically a waste of time. MFC on Windows sucks hard and Qt is simple the native go-to C++ toolkit for Linux.
That’s why your use case matters. If we are going down this path of thinking with no context, your application should not be a GUI application at all. But if you want easier future porting to iOS, that’s different than if you want easier future porting to xbox, and different again if you want it to run on ChromeOS.
QT is awesome, don’t hear me wrong. But if your target platform is distros running gnome, it might not even be the right choice for a native Linux desktop app. And again, none of this cross-platform compatibility discussion necessarily makes it a better choice than Xamarin stuff.
I’m just saying, it’s not “the” option. It’s just a very good choice.
If you want to use QWidgets, I highly recommend PyQt for beginners. PyQt is a very well done set of Python bindings. With rare exceptions, the Qt behavior and docs map straight over. E.g. if a method takes a QString, you can send it a Python string and it just works. It's dual-licensed GPL, so you do have to pay for it if you're selling something, but it's worth supporting the small company that produces it.
To be slightly pedantic, you are not required to pay for it just because you are selling something. The requirement is only that you comply with the terms of the GPL license by releasing source to any modifications that you ship.
... or the source to any code that uses PyQt. Nobody knows. It hasn't been tested in court. I'm not sure it's even been tested with C code that links against a GPL library. With Python you're another step removed because it's dynamic and the linking doesn't happen until it's on the consumer's computer.
Thats how the law work. A copyright owner go to a judge and say "The accused sold work based on my copyright" and the accused has to bring up the GPL as proof that they have permission, or they argue that the new combined work do not include any copyright-protected elements of the original. Its a grey area by design.
Linking technology itself is actually rather irrelevant to the legal questions that a court general ask in defining copyright. FSF happen use it as a bright line in the sand on where they will enforce the license, but any author can make their own decision on that matter. Game companies has for example gone after mods that inject itself through windows libraries, arguing that the mods purpose and existence is dependent on the original game and thus created a derivate work.
There was a historical case when a person legally bought a painting and cut it into several pieces only to stitched them together into a mosaic. The court judged it as a derivate work and thus requiring additional copyright permission from the author.
As with other gray areas in copyright, derivative work also have semi-exceptions. Compatibility is one. Since there is multiple different C standard libraries, it would be hard to argue that a program is specifically a derivative work of one. It would also be very easy to demonstrate the works independence by simply using a different standard library.
PyQt brings a interesting question but in the end I doubt it would be that much of a gray area. In theory you could make a program that is only compatible with Qt but don't actually depend on it, but in practice I suspect most such program do not start, operate, and function if you remove the Qt parts. In such cases I expect the accused will have a hard time arguing that the final work when used has no copyright-protected elements of Qt.
But by it being GPL, you also have to release the source code of your potentially proprietary code as GPL. It's LGPL where you only have to release the modifications to the library.
If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.
If you dynamically link to an LGPL library, then only the library must be under an LGPL-compatible license (ie if you modify the library, those modifications must be made available), but your own code that links to the library can be under any license you wish.
This is because the LGPL considers statically linking as a single work, while dynamic linking as multiple works, which can be licensed independently.
GPL:
Regardless of linkage, your code must be under a GPL compatible library.
The GPL considers the software as a single work regardless of linkage.
> If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.
This isn't right. You can statically link proprietary code to LGPL libraries and the LGPL license does not "infect" your proprietary code.
The only thing you have to do if you go this route is ensure that the people receiving your combined work are able to relink any modified version of the LGPL pieces. This can be done, for example, by providing object files for the proprietary pieces and a script to link them to the LGPL pieces, upon request.
Last I checked, the original PySide had been more or less abandoned around the time Qt5 came out, and the Qt Company was at work on PySide2. We'll see what comes of it; I haven't heard any big announcements, and it doesn't seem like a priority.
A sort-of left field suggestion would be to try Red [1].
I'm quite impressed with it, so far! However, I'm not sure how suitable it is considered to be for beginners.
I would think Ring [1] would be a better fit int he comments since Ring has QT bindings. Ring and Red seem to have the same goal of making GUI programming easy. Personally the syntax of these languages drives my inner Lisp brain a little crazy.
For QWidgets. If you want to use QtQuick, you're basically using javascript and/or C++ (I'm not personally complaining, I'm comfortable enough in C++). EDIT: seems there's rust bindings for QtQuick too.
Agreed! I use it at work for a CLI application that runs on an HPC environment.
All the niceties that Qt as a framework provides (file system, multi-threading [mutexes, threads, semaphores, etc], JSON, shared memory, CLI arg parsing, even a State Machine!!) are a huge productivity boost.
Where's the added value of Qt's support for multithreading when compared with the C++ standard support for multithreading? IIRC, Qt introduces the irrelevant QReadWriteLock and that's it. In fact, the only upside of Qt's multithreaded support is that they were developed to serve Qt's very particular needs.
Qt is awesome but one of its main problems is its insistence of duplicating standard components and coming up with subpar alternatives which are then forced upon developers.
30 years in the making, still waiting for that thing to actually exist.
How long have you been developing in C++? The standard is so little, there might as well not be one. I don't even think the printf() function takes the same arguments on all platform.
Last year I went through Anthony William's C++ Concurrency in Action to better understand the "new" threading library. No complaints. Actually, I've been using it in several components that are "pure C++" (i.e., no Qt, only STL).
My point of view is that, where I'm using Qt anyway, I might as well use its threading library for the very nice support it provides for other things such as signal-slot connections across threads.
In Norway it is a common knowledge that QT is a very reasonable choice for soft real-time. So I guess that is a reason people do not blog about it. One doesn't write about obvious things, does one?
IMO it is not, but it really depends on what you are a beginner in.
If you are comfortable with C++ and both traditional and event driven flows, Qt is worth a look -- you may love it or hate it, but you will have something to compare it to and know enough to form your own opinion. Otherwise, pick at least 3 different languages/toolkits and implement a simple application in each to be aware of different ways of doing the same thing. Repeat for a different simple application.
This vaccinates you against taking a model of your first toolkit and using it as the only way to solve every problem.
That said, Qt is a solid cross platform toolkit that you can use it to write robust applications. However, it severely locks down your choices. If you use it, force yourself to at least be aware of other options. My 2c.
It's a hard question, because on one hand nothing beats the next-next-finish install and setup experience of Visual Studio with C# on Windows, but it gets you exactly nowhere. (Okay you can make pretty programs that have a lot of buttons, input boxes, dropdown lists, and so on.) But that's a very good place to be, because then you can start branching out depending on what you find interesting.
I was researching a GUI framework for creating a desktop tool (that is a not very memory or CPU intensive). I felt that Electron was good enough. For the GUI framework it seemed like I can make do with Photonkit[1] and ReactJs.
Is your remark about the memory requirements about what the tool's functionality itself would consume, or the complete application (including the Electron runtime)? I was under the impression that each Electron application would require as much memory as an instance of the Chrome browser.
Yes. I was not building an application like Tableau or IntelliJ. I also was not building anything that had high performance requirements (which electron will definitely fail at) it was a CRUD app - the desktop version of a website with sync functionality.
The learning curve and full fledgedness of Qt was not needed for me.
Electron seems to be the preferred approach these days (much disliked by people who appreciate native apps). That said most Qt apps don't look native all the time either (it comes close enough)
For a beginner (that knows C++) I would think Electron is way more difficult than Qt. With Qt you just: 1. Download the Qt SDK, 2. Start Qt Creator, 3. Open an example, 4. Click Run.
I wouldn't even begin to know where to start with Electron. There are so many web frameworks and they're all badly documented... whenever I have to make a website I usually start off thinking "Right, I'll do it the 'modern' way this time - with React or Vue... and Typescript.. and and do I need webpack? and...??" but there's so much badly-documented half-finished stuff out there I usually end up giving up and doing plain Javascript. Doesn't help that the modern web stack is a total hacky mess.
This is definitely the state of things. It's funny how people talk as if writing a web application is somehow inherently easier and more efficient than native applications. It's most certainly not the case. You have know at least 3 mediocre languages: HTML, CSS, and JavaScript. And then a separate server-side language if you're not a JavaScript fanboy, most likely a templating language server-side, and maybe even a client-side templating language if you're into that sort of thing.
I'd gladly take Qt with C++ any day even though I only know enough C++ to shoot myself in the foot with.
For a long time I thought that C++ was somehow a bad language (because that's the developer-talk-consensus, much like Java), but after I've written a decent amount (something like 100k loc or so as of now) in C++ I reversed my "opinion". C++ allows people to write code that requires intense study to understand (template magic etc.), but writing that code and getting it to work is very hard too, so there is actually very little of that around. Apart from that C++ is a good language which works well for developing applications (and Qt is a very good partner for it). And that's what really matters.
(Another thing that comes to mind is that there is a huge amount of software for testing, analysing, introspecting and debugging C++ applications - I would say that most other ecosystems are lagging behind in that aspect)
I think a lot of the broad criticism of C++ is from people who don't use it professionally and have a superficial understanding of it. Professionals usually have specific criticisms of C++ (based on actual problems) which non-professionals interpret as "everyone hates C++". I use C++ professionally and I'm rarely frustrated by it. The language is getting better over time, which is nice too.
Why would you even want to use JS on desktop if you have other options available? JS is the choice on the Web, because it's the only choice. It's the choice on Electron, because you can share the code base with Web version or make stuff like editors targeted to JS developers, so they can hack them while using them. But otherwise, it seems like the only worse option you could use for desktop apps is PHP. Why are people doing it to themselves?
Since we're in a submission about Qt: if you really don't want to touch C++ (which is kinda understandable, although C++ with Qt actually isn't that bad), Qt is very well supported in Python. Using them together is a breeze, and if you really do miss the craziness of JavaScript, you can still use it in QML :P
And if QML is what you only care about, you can even wrap it with Rust.
JS is a pretty good option in many cases, easier to support in many platforms and arguably easier to develop and debug. What is not, though, is bundling a whole browser. A JS engine is a couple orders of magnitude smaller than a browser.
I've been a professional JS developer for a few years, doing both in-browser and node-based automation stuff (never desktop apps in JS though, thankfully). What I mean is that while new JS revisions are trying to catch up and become somewhat pleasant to write in, there's still tons of baggage of bad decisions from the past that make this language simply awful when compared to basically any other popular language - and those aren't stagnating either.
Just in order to retain your sanity, you need to use several layers above JS to transpile your code - like JSX when you do UI or TypeScript when you do... well, anything.
I believe that JS is considered easy only because you can get your first impressive results very quickly when combined with HTML and CSS, which makes it easy to not lose your focus when learning. That might make it a good language to learn in, say, primary school on IT lessons - of course, only if there weren't other, better suited stuff available targeting these cases specifically already. Anything else actually makes JS harder than, say, Python. Or Go. Or C#. Or Java. Or even C++ with Qt (although C++ is easily second worse). Or Rust. There's just so much stuff you have to keep in your head while writing JS, it's not worth it. But you have to let go of "I know it, so I'll use it, no matter how well suited it is" mentality, and that can be challenging.
> Anything else actually makes JS harder than, say, Python.
It depends on the setup. I use CoffeeScript 2 which gives me most of what I miss from Python (which was my favorite language for years). And when I go back to Python I miss having a debugger as good as Chrome's, as well as some CS2/ES6 features.
> There's just so much stuff you have to keep in your head while writing JS, it's not worth it.
This alone clearly states that you known nothing abou C++ beyond tired old, meaningless clichés about irrelevant stuff you've heard somewhere and are complaining about something you know nothing about.
How? Has C++ eliminated undefined behaviour recently? Yes, you can avoid it but it requires years of experience, a significant cognitive load as you work, linting/testing tools and you have to hope all the libraries you're using plus your team members have the same high standard that you're trying to follow yourself. I used C++ for years and knowing there are other languages out there I have no interest in making life hard for myself.
Because you're repeatedly showing profound ignorance on very basic aspects of using a programming language.
> Has C++ eliminated undefined behaviour recently?
You are aware that you're parroting on and on about an entirely irrelevant issue, don't you? I mean, any behaviour which has been left undefined in the international standard only means that there is a chance that two implementations may not implement the same obscure aspect exactly alike. And that's perfectly fine because these obscure corner cases shouldn't be used to begin with. That's what undefined behaviour does mean in practice.
But even if you for some obscure and irrational reason care enough to rely on behaviour left undefined then you also go another standard approach: adopt a specific implementation and check how the behavior was implemented.
Additionally, rust and go and python and other programming languages are not defined at all and somehow programmers don't get bothered by the fact that these programming languages are entirely undefined. But somehow you feel differently about a language you clearly know nothing about.
> But even if you for some obscure and irrational reason care enough to rely on behaviour left undefined then you also go another standard approach: adopt a specific implementation and check how the behavior was implemented.
By undefined behaviour, I mean things like null dereferences, buffer overflows, memory leaks etc. that are done by accident and result in serious issues at runtime. I'd rather use a safer language where I can be more productive where possible.
Sounds like you're talking about implementation defined behaviour or unspecified
behaviour which are different from undefined behaviour (these three terms are defined in the C++ standard document).
> But somehow you feel differently about a language you clearly know nothing about.
You're not even trying to understand the point you're leaping to attack. You clearly have a chip on your shoulder about something.
Here's 1,605 pages of defined behavior. What language are you comparing it to with more completely-defined behavior that can be translated to efficient native binary code for as many different architectures?
The anti-Electron people's complaint isn't really the look as much as performance and mostly start up time. To me I sue several electron apps all day and they have held up well.
RStudio
VS Code
Discord / Slack (Well slack has not been rock steady)
