4 ms·

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

by geokon 10y ago

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++?

blub 10y ago
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.
- geokon 10y ago
  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.
dom0 10y ago
> And is this all a lot less of a headache than I'm imagining? It really isn't much of a headache.

by geokon 10y ago

blub 10y ago

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.

geokon 10y ago
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.

dom0 10y ago

> And is this all a lot less of a headache than I'm imagining? It really isn't much of a headache.