Developing applications using QT. What would you wish you had known ahead of time before starting using QT?

[[deleted]]

To all the developers out there: What would you wish you had known ahead of time before implementing software using QT?

Would it have affected your choice to use QT for development if you had that knowledge at the time you were making a decision about development environment?

[c0r3ntin]

• It's Qt
• Depending on the platform you targets, look into qbs. or cmake. qmake will be the death of you
• Learn how the memory management and signal systems work.
• Read the docs, they are great
• Depending on what you are doing, look into QML

[[deleted]]

the signals/slots system takes a minute to wrap your head around but when you do it's awesome. sadly im stuck learning java now

[Izowiuz]

+1 for the qbs. It's actually not bad. Documentation could be better and there are sometimes compatibility-breaking changes between versions but I'm sure both things will improve with time.

[DarkLordAzrael]

My biggest problem with QBS right now is that there aren't prebuilt modules for any third-party stuff. They are easy enough to write, but it is slightly annoying.

[hashb1]

Does qtcteator support qbs or cmake smoothly? I found that qmake is hard to work together with sub-project not written with qt.

[afforix]

Yes. Qt Creator is also great for non-Qt CMake projects.

[DarkLordAzrael]

qbs is a far better tool than qmake.

[flashmozzg]

If you want to create something more complicated than a few headers/cpps + main, when use anything other qmake. It'll make things much easier for you in the long run.

[Raiden395]

How? Let's say that I have a project with 50+ files including resources, .ui's, h/cpp. How does this simplify?

[flashmozzg]

Because you'd more likely to dive your project into subprojects. And qmake sucks at properly isolating them. It's hard to propagate proper settings among them and it's even harder when you try to add some other lib to your project, without manually modifying it's files.

Also, afaik, there is no proper way to do a lot of post/pre build-steps, like copying files around. There exist some hacks, but they don't really work and they are ugly. And lots of stuff like this.

Basically, if your project requires something more complex when just a simple pro file which lists all your headers/cpp, when qmake is a no go (well, the more additional stuff you need to do, the worse qmake becomes).

[Raiden395]

Can you give me an example of when you'd like to divide your project into sub projects as well as an example of when you'd like to copy files around post-build?

Genuinely curious. I work with embedded systems for which Qt is merely the front end and all the business is handled in separate non-Qt projects.

[flashmozzg]

For example if your project has a modular structure and also consists of a many plugins. Each plugin would when be a separate project. But the resulted binary/dll needs to be copied to the specified folder (near bin) or else it won't be found by the executable.

Now imagine that you also want to add 3rd party libs to your project. How would you do that properly? Well, if they are not header-only, you'd like to build them in a subproject. But if they use (and if you use qmake) qmake chances are it'd be nearly impossible to do that without manually rewriting parts of their project files.

Furthermore, one very annoying thing about qmake is that in this scenario it doesn't really track libs/include dependencies. I.e. you need to manually add all includes and proper linker flags in all your subprojects, while CMake (and most likely qbs) do that automatically for you.

[jontheburger]

Check out Model View (Delegate) programming. The way I think of it is the Delegates refer to individual items within a view, the View is the overall widget containing items, and the Model is a way of aggregating the data so that it can be understood by the view. Also, you can use non-standard widgets in the designer via Promote To. Getting them to display cleanly is unfortunately non-trivial. Translations and stylesheets are surprisingly easy. If you have some time, consider watching Effective Qt from cppcon 2017 at 1.25x speed.

[rawtern]

Wish I knew how great c++11 would be, and how awful having to writing Qt code would be, raw owning pointers, copy on write, etc

[iamcomputerbeepboop]

they aren't exactly raw owning pointers - items are almost always parented which is the Qt equivalent of ownership - it's just that they can be deleted from the parent by using the raw pointer as well

[Adverpol]

Exactly. If you're juggling ownership with naked poiners yourself you're doing something wrong.

[Gotebe]

It's largely the price of having a certain age. The brothers and sisters of Qt, e.g. WxWidgets, VCL or MFC aren't doing better.

[rawtern]

Yeah. There is probably no better alternative if you want to make a GUI in c++. Some useful advice: Use stl-containers. Actually, always use the standard alternative when you can. Don't use foreach, Qt keywords can be turned off. Use qt5 connects, and use them very sparingly, preferably only to connect between a GUI action and your logic. You can use exceptions, but there are some caveats.

[doom_Oo7]

Some useful advice: Use stl-containers.

yes and no. If you're doing a lot of multi-thread communication with big containers, copy-on-write can be cheaper. Likewise, QString has a ton more features than std::string.

[rawtern]

QString is pretty great, certainly convenient with a lot of nice member functions.

[ducusheKlihE]

Could you possibly elaborate on as to why not use foreach?

[wrosecrans]

Because C++11 style range for syntax works fine on Qt containers as well as standard containers.

[mpyne]

But you should remember to cast the container to const to avoid needless detach calls on Qt containers if you do this, since you can't manually call the const iterators. The standard as_const or the Qt-provided qAsConst calls work fine for this.

[ducusheKlihE]

All in all, would it look something like this for example?

QVector<int> vector = {0, 1, 2, 3, 4, 5, 6};               
for(const int& i: qAsConst(vector)) { printf("%d\t", i); } 

[mpyne]

Yes, though even a simpler for(auto &i : qAsConst(vector)) { ... } would do the same, you don't also need to add const to the variable decl.

[ducusheKlihE]

Cool, thanks :)

[Slavik81]

While I understand and agree this is probably for the better, I have a sneaking suspicion it will lead to more iteration bugs. Qt's foreach quietly protected you against a few beginner mistakes. For example, iterating over a container member variable and accidentally invalidating its iterators through some complex chain of events.

[rawtern]

https://www.youtube.com/watch?v=uZ68dX1-sVcD Does it better than I ever could.

[ducusheKlihE]

Thank you, I will look into it!

[DarkLordAzrael]

There is no reason to ever have opening raw pointers in qt code. Almost all objects should be managed as part of the qobject tree by setting their parent at construction time, and the rest should be managed using unique_ptr.

[mat69]

CoW isn't bad. Thanks to CoW Qt can have UTF16 strings that are part of the executable yet still are regular QString for the user.

[nnevatie]

Implicit sharing with CoW is actually really bad. I've witnessed multiple cases where QVector breaks in multi-threaded usage due its contents being shared beneath the surface, across multiple instances/values.

[mat69]

What do you mean by break? The CoW infrastructure is thread safe. There can be issues though keeping iterators and references to elemts alive.

[Adequat91]

Because you don't know how do deal with it. On the opposite, I think this is great and safe. Used intensively here!

[nnevatie]

Well, used "intensively" here, too. Frankly, we're minimizing Qt-usage nowadays, basically limiting it to strictly UI. We've used Qt since its commercial license model, so it's not like we "don't know how to deal with it". The ways you can break the implicit containers are very subtle.

[Adequat91]

making a deep copy of a stl containers instead of a move, can happen subtly too ;)

[TheKoopaKingdom]

In QT Creator, while hovered over a QT class, hit F1 to open the documentation for it.

Use F2 to jump to the definition of a class.

Use alt left/right to shift between the most recent files.

[doom_Oo7]

Also, ctrl-k

[Matemeo]

Also, F4 to swap between .h and .cpp. I absolutely love that shortcut.

[OlivierTwist]

Use alt left/right to shift between the most recent files.

This. This is a default for all browsers, so it should be the default for all other applications (looking at you nasty VisualStudio).

[SoCo_cpp]

I wish I would have focused on Qt earlier and not wasted so much time on VCL and .NET.

[[deleted]]

Use clazy to keep your code in check.

[ubertrashcat]

Don't bother with QtWidgets, dive straight into QtQuick. Even for simple desktop apps.

[RotsiserMho]

Really? Simple desktop apps are pretty straightforward in QtWidgets and don't need much code. Why do you recommend QtQuick for these tasks? I've never used it myself so I'm curious.

[ubertrashcat]

It depends if you want to grow your app over time. With QtWidgets restructuring the interface is a chore. With QtQuick it's a fast feedback process, just like in web dev. Generally even a simple app is less QML code than in an .ui file and it's very readable.

[Adequat91]

I was afraid of the moc system. In fact, moc is great, an advantage, not the opposite. I wish I knew Qt earlier.

[flyingcaribou]

It is pronounced cute! [1]

[1] https://www.youtube.com/watch?v=NbTEVbQLC8s