More Reasons For Not Using Web

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.”
  • Availability of a certain Web technology in 10 years: “Modern HTML5-based applications that use frameworks like AngularJS are relatively new and undergo changes from year to year – a valid question is whether AngularJS (or any other currently trendy Javascript-library) will still be a relevant HTML5-technology in 10 years.”

Writing Apps for GM Cars

Just three years ago, this would have been unthinkable. GM publishes an SDK (NGI SDK) to write apps for the infotainment systems of its cars and an app (GM Dev Client) to run the app in the car.

General Motors has launched GM Dev Client, an industry-first app that gives approved developers who have created in-vehicle applications the ability to test them in a real GM vehicle. In-vehicle app testing is the next step for app developers who have already created a proof of concept using GM’s next-generation infotainment software development kit (NGI SDK).

Of course, you need a car or at least access to a car from one of GM’s brands, which is a bit tricky in Europe. And, it is must be a model from 2017 or newer.

By the way, these third-party apps are written with Web technologies (HTML/CSS/JavaScript).

Will Android Take Over In-Vehicle Infotainment?

For Nathan Tennies from Barr Group, the answer seems to be a resounding “yes”:

It’s frankly hard to see how automakers using AGL—or other infotainment platforms—will be able to keep up with Google. […] And for some automakers, putting the kibosh on Google may ultimately be more important than providing customers with the best IVI experience […] But mobile giant Samsung provides a cautionary tale about the difficulties of competing with Android.

Samsung and the other Android handset makers provide a cautionary tale why using Android is a bad idea. The premium handset market is heavily dominated by Apple’s iOS. Customers are willing to pay prices of 700 Euros and more for an iPhone, because iOS is the big differentiator from Android.

Why should customers pay 700 Euros for Android phones, if 300 Euro Android phones are good enough for them! Android OEMs can only differentiate on price. And their average selling prices have been declining for years.

Car OEMs would be stupid to bet on Android. They would give away an easy and compelling way for differentiation. I can’t see this happening for premium car makers like Daimler, BMW, Porsche and Tesla. They are currently investing heavily in operating systems other than Android.

ICS on QtCommercial: “Fee is Better Than Free”

Mark Hatch, the COO of the Qt consultancy ICS, gives four strong arguments, why projects should pay for Qt Commercial instead of using Qt under LGPLv3 for free:

  • Reduced obligations/greater flexibility of distribution
  • Additional features
  • Technical support
  • License negotiation

Mark’s argument would be so much stronger, if The Qt Company published its license fees or at least gave some ballpark figures. If potential customers had a rough idea of the costs, they would think something like this: “Wow, Qt Commercial is much cheaper than I thought. I get some killer features on top of the free license. I have absolute peace of mind when deploying my application on devices. Let’s contact sales. I am sure I can get a good discount.”

Now compare this with the current situation: “I hate calling sales people to get a first quote. They’ll call me twice a week for the next four weeks. I really hate this. OK, I’ll call them next week.” It is unlikely that Qt Sales will ever hear of this potential customer.

CMake Cross-Compilation Based on Yocto SDK

We have succeeded in building embedded Linux with Yocto for a quad-core NXP i.MX6 (ARM Cortex-A9). Next, we want to cross-compile our own Qt application. As we use CMake for building our Qt application, we must create a CMake toolchain file. I am going to give a line-line by line explanation of the CMake toolchain file. I used Yocto Morty and CMake v3.5.1 (as it comes with Ubuntu 16.04 LTS).
Continue reading

Qt vs. Web (Part 1): Three Cautionary Stories About Web

Let XXX be a manufacturer of printers, TVs, set-top boxes (STBs) or home appliances. XXX must decide whether to use Qt or Web for the HMI of their devices. I’ll start my series “Qt vs. Web” with three cautionary stories about using Web technologies. Facebook moved from Web to native. Netflix built its own rendering engine and JavaScript HMI library to continue with Web technologies. Although LG’s smart TVs run on WebOS, the built-in and brand-critical TV UI uses QML and Qt. Third-party apps use standard Web technologies.
Continue reading

30% Faster Startup Thanks to QtQuick Compiler

It is not easy to find hard data about how much the QtQuick compiler can speed up the startup of real-life application. As I had some time on my hands this weekend, I measured the startup times of the HMI of a maize harvester running on a quad-core NXP/Freescale i.MX6 (Nit6Q_W_BCOM). Using the QtQuick compiler from Qt 5.7 brings the startup time from 2.72s down to 1.91s – a speedup of 30%!
Continue reading

Boot2Qt Open-Sourced as Part of Yocto

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!