Hacker News Reader

Comment by irishcoffee | Hacker News Reader

Obligatory: Qt.

I've been tasked as a Qt dev at my day job for the past ~2.5 years writing cross-platform applications. It works, the documentation is pretty fantastic, and you'll find no shortage of help online to get over the admittedly decent learning curve if this is your first swing at "c++" programming.

Edit: As mentioned below, PyQt is also pretty fantastic. My most recent venture into the PyQt world at work was writing a touchscreen application on a 800x450 touchscreen, and it all "just worked."

View on HN

Seconded:

- QT is a great and very-well designed library with solid performance, a fast release cycle and superb documentation.

- It provides a rich and well thought-out component library.

- It is used by many companies to build real-world applications.

- It has a pretty liberal licensing scheme. The commercial license (if you need it) is not that expensive.

- It provides bindings for many scripting languages like Python.

- It has great IDE support and lots of tooling around the core library that make GUI design easier.

- It emabraces model-driven design and has stylable components (via CSS).

- It will usually beat most JS / WebKit based frameworks by a large margin performance-wise and makes distribution of your application much easier (forget about >100 MB downloads).

FWIW its version of CSS is just terrible, there are a lot of properties you cannot control with it (e.g. display properties), its style inheritance model is equally terrible (for some reason if you do .foo, the foo object will get the style as will all of foo's children), and forget about animations. To be fair, I did test it out at v5 and they may have improved it, but at that time it was by no means a fair thing to call it css.

And that's why they call it QSS (Qt style sheets). :)

- The commercial license (if you need it) is not that expensive.

I consider it very expensive. More than +US 3000/year for 1 developer?

The open-source is useless for desktop apps?.

Why is the open-source version useless for desktop apps?

Is there any Qt app for the Mac that doesn't land in the uncanny valley of UI? I've not been impressed with the apps I've tried.

One real world success story for Qt:

Andy Brice (Oryx Digital, UK) has been developing his successful desktop software product, Perfect Table Plan (a seating planner software for events), in C++ and Qt, and selling it for over 10 years. (His newer product HyperPlan may be done in that stack too.) I've been a reader of his blog from some time: successfulsoftware.net. Many good tech and more biz tips there (for the software product biz - for desktop apps). And his app is cross-platform between at least two of the big 3 consumer OS's, IIRC (or maybe all 3) - Windows, Linux and MacOS.

Edit: I had also checked out Qt (v3 or 4) and tried some of the example apps (reading, compiling and running them) and also bought and read most of a book on Qt programming by some well-known Qt developers (don't remember the book or author names right now, but they may have included some of the original Qt creators). The impression I came away with was similar to that of some of the other commenters here - Qt seemed to be a well-designed library, not too difficult to learn, and with fairly good documentation at the time. I could understand the signals and slots mechanism it uses, without much trouble. Didn't get the moc part though (was not a C++ expert, also did not look much into moc) but it may not be needed to know that well, may be enough just to be able to use it.

> moc

FWIW I never had to delve into understanding what exactly it does apart from "is invoked by build system to generate some code" in the course of many years of working with Qt.

Good to know, thanks.

I program in C++ professionally and about every 6 months I get the Qt tingle and think "I should really get around to learning Qt". But whenever I start to look into it I start to feel like I'm supposed to learning some custom language and it's not C++ at all - and how am I going to work this into the rest of my workflow

I've got a pretty vanilla workflow with CMake, the GNU tools, the STL and emacs/KDevelop/CLI to tie it together. It works across all platforms and all problem domains. But the internet is telling me that if I want to make native GUIs I have to be in the parallel universe of Qt with its own version of CMake, some magic custom build steps, its own IDE and some XML stuff that you really really should use otherwise things will get messy.

Is this just b/c Qt is old? Is there a bigger reason for the Qt-verse I'm just not seeing? And is this all a lot less of a headache than I'm imagining?

PS: Are there any clean frameworks that are tied to modern C++?

I don't know any such frameworks. Building a quality one takes a lot of work and time, I guess most of them are decades old at this point.

I've included some answers below:

* One can use Qt with CMake and for a large project probably should, because qmake can be quite limited.

* Qt Creator is not a must, but it's a good C++ IDE and was designed to work well with Qt. I think KDevelop should have pretty good Qt support too.

* The only XML I can think of are the UI designer files. If you prefer you can write the UI code by hand, but it's quite barbaric IMO :) Those files are just parsed and transformed into a ui_foo.h file which contains an inline setupUi method that one should call from their widget's constructor.

* The custom build step is running the meta-object compiler. It's necessary for signals and slots (Qt's ubiquitous subject-observer implementation) and for e.g. reflection if used. This is only really needed for classes that inherit from QObject, such as all the UI classes. If you want to be really hard-core, you can build the entire UI in code, without inheriting from the UI classes, and then I think this extra build step is not needed, but you will lose covenience and some customization possibilities. They've also added signal-to-lambda connections, so one is not obliged to use slots at all AFAIK.

All in all it's not bad at all. If one wants to have a cleanly separate Qt and pure C++ code-base it's possible with some glue code.

thanks! I guess you're right, it doesn't seem so bad. I might dig into this more next time I have a project that needs a UI.

> And is this all a lot less of a headache than I'm imagining?

It really isn't much of a headache.

Or wxWidgets for a native GUI look.

PyQT is a nice alternative if you don't know/want to program in C++ .

AFAIK Qt also has support for writing apps in JS (isn't that what Qml is?).

Yes and no. You need a C++ skeleton to integrate the Qml files. Also Qml/JS is slow and doesn't support all the features of Qt/C++. Practically you use Qml for the GUI, but C++ for the logic.

Or you can create components in C++ callable from Qml, but this requires some extra code ( and work ).

> As mentioned below, PyQt is also pretty fantastic.

Isn't Python just as slow as Electron?

Qt ought to be a thinner layer than Electron, and most computation-heavy things you'd do in Python end up in the C libraries that the modules are implemented in, anyhow.

I've tried Qt creator and during typing it uses ~20% of my CPU, the same visual studio code uses.

Reply on news.ycombinator.com