The Qt Company published a guest post “Qt QML v HTML5 – a practical comparison” and a whitepaper by the Austrian Qt consultancy Sequality. Sequality had one developer writing a simplified application for controlling a bottling plant first with Qt and then with Web (AngularJS). The developer had 160 hours for each implementation. The application had to run on a tablet, a PC and a Raspberry Pi 3 with different resolutions.
Here are my favourite findings of Sequality’s experiment.
- The developer finished considerably more functionality with QML than with Web.
- Higher efforts to use OpenGL acceleration for Web: “Enabling GPU rendering on Chromium […] doesn’t fix the HTML5 demo’s performance problem. In fact, the CPU is utilized even more, which leads to overheating.”
- Higher efforts for testing Web: “The fact that HTML5 applications can be executed on a number of platforms – and a number of browser engines on each platform – multiplies the testing time correspondingly.”
Tuukka Turunen from The Qt Company shared some fantastic news in his post Aligning with the Yocto Project.
We have created a separate Boot to Qt meta layer, meta-boot2qt, which takes care of building the images and toolchains for the reference devices. The meta-boot2qt layer integrates all the required BSP meta layers, so there is no manual configurations necessary when starting Yocto build for one of the Qt reference devices. The layer was previously available only for our commercial customers, but with Qt 5.7 we have open sourced it as well.
The Boot2Qt meta layer comes with support for all three versions of the Raspberry Pi, many i.MX6 boards (Nitrogen6x, SABRE, Colibri, etc.), the NVIDIA Drive CX and for the Intel NUC. This should make the live of embedded Qt developers a lot easier. Thank you very much, Trolls!
Move semantics is faster than copy semantics, when the compiler can replace expensive copy operations by cheaper move operations, that is, when it can replace a deep copy of a big object by a shallow copy of the pointer to the big object. Hence, classes using the pimpl idiom in combination with move semantics should see a considerable speed-up. As Qt applies the pimpl idiom consistently to every non-trivial Qt class, we should see a speed-up by simply using Qt classes instead of their STL counterparts. I’ll compare the performance of classes that use move semantics with Qt and STL classes with and without applying the pimpl idiom.
Recently, I looked through the code base of a medium-sized project to see how I could simplify handwritten for-loops by using C++11’s new range-based for and STL algorithms with lambda expressions. The results in short: Range-based for makes loops simpler, easier to understand and often faster. STL algorithms are often a bit harder to read and write than range-based for loops, because lambda expressions are pretty clumsy, algorithm naming is inconsistent, and algorithm interfaces are inconvenient. But, they are still better than handwritten for-loops.
The answer to the question in the title is a resounding “maybe”. The writer of a piece of code wanted to avoid a division-by-zero error by checking whether the divisor of type
float is not equal to 0.0f.
In this post, I want to show some examples how C++11’s initializer lists can improve some typical Qt code. I’ll show how C++11 makes the initialisation of container-type variables very simple and how it makes static const data members possible at all.
Up to Qt 5.3, things were pretty simple. Most modules were under LGPLv2.1 with the exception of some commercial modules. Starting with Qt 5.4, new Qt modules were published under LGPLv3 and old modules additionally under LGPLv3. With Qt 5.6, we now have quite a patchwork of modules under different licenses. Qt 5.7 will drop LGPLv2.1 completely. Some companies stay on Qt 5.3, because they are afraid of LGPLv3. Let me bring some clarity into this patchwork and explain how you can still use Qt under LGPL and sleep well.
The maize harvest is in full swing. The harvester runs nearly 24/7. The driver notices a drop in the area cut per hour. He calls tech support and starts sharing the screen of the terminal in the harvester. The support technician guides guides the driver through changing some machine parameters. All is fine again. My Italian business partner, Ispirata, and I developed a VNC server for the Freescale i.MX53 terminal of Krone’s BiGX forage harvester – to make this scenario possible.
Recently, I brought up Qt 5.5 on a Freescale i.MX35, which has an ARM11 CPU but no OpenGL support. Despite the missing OpenGL, I wanted to write the HMI with QML. The additional challenge was that the cross-compilation toolchain was 32-bit, but I wanted to use my standard 64-bit Ubuntu. I’ll show in this post how to set up the 32-bit toolchain and rootfs on my 64-bit Ubuntu machine, how to configure and build Qt 5.5 from the sources, and how to run a hello-world application written in QML on the i.MX35. Continue reading