I spend a bunch of time on researching/implementing Qt with C++ in MetricGym. We have ported it from JAVA. Enhanced the codebase. Actually nothing special.
Actually programming this in Qt was easier, because you don’t have to work so much with threads and it is still working (somehow ;)).
Why we rewrote it to Qt/C++
We have a heavy usage of websockets & serial port. The SerialPort library in JAVA sucks. When the connection drops in both cases, sometimes it won’t reconnect back. We tried with workarounds but still, no success. It does not really give you a state when the connection has been dropped.
Being furious about the events and lack of stability that gave us the library - I decided to port it to Qt/C++. First of all - this is “cross-platform”. We have clients using multiple OS’es. It is feature rich. We literally didn’t needed to add a library beyond Qt to handle serial ports and websockets.
Qt is “cross-platform”
I didn’t knew much about Qt with C++. I have worked before with PySide and created a simple applications with that. I downloaded Qt Creator for Linux (my daily driver) and followed my motto “just do it”. Creating the UI is really easy. UI is created via “Design” editor. You only need to code functionality like saving settings (which qt also have a module for it) etc. The problem is that if something works on linux (like even reconnecting websocket after a connection drop), it doesn’t mean that it will work on windows. You have to test your implementation on both systems. You have to write workarounds.
Second problem is also about writing shared objects. As you may guess there are also problems with incompactibility of Windows. There wasn’t such hard problem but still - “cross-platform”. You have to add some headers, attributes to class in order to work. So it wasn’t such a problem.
QtWebSocket - my biggest concern
QtWebSocket isn’t well explained in the documentation. You can get problems with connecting to a websocket secure host. You have to figure out what UnsupportedSocketOperationError really means.
According to the documentation, it should mean The requested socket operation is not supported by the local operating system (e.g., lack of IPv6 support).. The problem really can be that you don’t have SSL with a specific older version of dlls with the correct COMPILED cpu architecture provided. Trust me, Stackoverflow, IRC doesn’t help here much.
Positives: QSerialPort
It is well documented. Unfortunately we had to write our own CRC-16 CCITT implementation that our pos printer is accepting. I don’t count it as a con for Qt, but for the printer :). It was a good experience. Unfortunately I couldn’t get a pos printer locally so I had to program like in the old times on paper :P. I’ve tested my implementation on my boss’ device over teamviewer (fun times). Still, there were problems with reconnecting on windows, but having a workaround from websocket, it ran smoothly. Overall there was no big problems.
Positives: signals, slots
It was a very pleasure and cool thing to use QObject::connect. For example you define a signal method in your main websocket handler class and slot in your GUI class. You don’t have to fight with threads and stuff. Just connect it, emit in your websocket handler with data and it will put into your main gui class.
Conclusion
We needed 1 month to develop our desktop client. we spend approximately 1 week on fighting bugs. If you ask me which tool will I use to create next desktop project, I would choose Qt/C++. At the beginning you have to understand the “Qt way”. Otherwise you gonna go in a trap like me with reconnecting issues.