The DevelopEx company widely applies the Qt framework for developing projects that should work both on a desktop and on other platforms. No need to remember about the huge advantage to develop several sub-projects just as if it were one. Not to mention the ability to build a project for as many platforms as needed just by using the appropriate toolchains.
Our DevOps engineers do not care about how to deliver the builds to a QA department because we’ve implemented continuous integration with Jenkins. The automation server builds and uploads project files to internal storage automatically. The project manager does not have any worries about risks when the application is updated because the code is structured in a Model-View-Presenter MVP pattern. This means that in case of issuer or updates it is enough to modify a single “model” logic. And sometimes (but rarely) in “presenter logic” that is separate for each platform. As the code is written in C++ and compiled by GCC to binary, a Qt application executes as fast as it would be if it is written in a native IDE.
We as an outsource company see the following advantages of Qt:
- Development is extremely fast,
- Easy to modify and extend any application,
- Easy to localize an application using Qt Linguist,
- A large number of libraries with intuitive APIs for threading, networking, animations and more,
- Excellent documentation, good support, and community,
- No effect of unparalleled development for different platforms,
- UI of applications are the same on different platforms,
- Qt was proven by time and has been vetted by major players,
- An application that is fast because it is binary,
- Easy to integrate low-level programming,
- It is dual-licensed: both free and commercial.
Spheres of application
It is said Qt is just a GUI toolkit. Yes, Qt is the best choice when an application’s UI should behave in the same way on different operating systems. But generally speaking, Qt is just a large C++ library (yes, with a cute IDE and other goodies). That is why any project could be realized using Qt. The proof is in a large number of projects that have been written using Qt. The technology branches where Qt has been applied are:
- Smart TV, TV Industry, Entertainment systems, In-vehicle infotainment;
- Navigation and info systems;
- Sound processing, eye tracking and image processing, graphics software;
- VR and Augmented Reality – AR;
- Touch-control user interface, 3D-printing applications, Human-machine-systems interface;
- Business and intelligence analysis;
- Medical systems;
- Ship automation systems;
- Operation systems;
- Security encryption applications.
Qt supports many requirements that are satisfied nowadays with business apps. The framework allows you to access a backend API via WebSockets or REST/HTTP. It is possible to add maps and location along with the display HTML5 content. No problem to organize access to sensors, work with multimedia and databases, connect via Bluetooth LE or NFC. The built-in localization features are also a huge advantage.
It’s a stupid idea to highlight some “main” and “periphery” components in the Qt. Because all of it matters. Nevertheless, there are some Qt modules that simplify the life of both the developer and customer incredibly. Subjectively, there are:
- QML – is a JSON-like declarative language for designing user interface-centric applications.
- Qt Designer – allows you to create dialogs and forms in WYSIWYG mode.
- Qt Linguist – simplifies the localization and translation of a program.
- Qt Assistant – allows you to create cross-platform help for software.
- And everything else 🙂
Qt has a complex system of licensing. The license depends on what is needed to develop a product. Basically, there is an open source (GPLv3 and LGPLv3) and commercial licenses.
LGPL differs from GPL in that not all components of Qt are available under LGPL.
For example, Qt Charts, Qt Data Visualization, and Qt Virtual Keyboard are available only under GPL.
Commercial licenses are divided into three types:
- Qt for Application Development – application development.
- Qt for Device Creation – development of embedded solutions.
- Automotive Suite is an instrument cluster (IC) and an in-car entertainment system (IVI).
Figure 2. Types of Qt Commercial Licenses.
From a technical point of view, the subsequent product includes the previous one and adds new components and tools. Basically, if you create a coffee machine and use Qt then you must have a Qt for Device Creation license because it is a licensed use of Qt.
Brief differences between licensing are given in the table below.
|QA and test reports||no||no||yes|
|Qt Charts (Qt 5.7)||yes||no||yes|
|Qt Data Visualization (Qt 5.7)||yes||no||yes|
|Qt Virtual Keyboard (Qt 5.7)||yes||no||yes|
|Qt Quick Compiler||no||no||yes|
|Qt Quick 2D Renderer (Qt 5.8)||yes||no||yes|
|ISO 7000 icon library||no||no||yes|
|CPU Usage Analyzer||no||no||yes|
|Qt Configuration Tool||no||no||yes|
|Qt Device Utilities||yes||no||yes|
|pre-built Boot to Qt images||no||no||yes|
|Qt 3D Studio||yes||no||yes|
|Qt Application Manager||yes||no||yes|
Table 1. Different types of Qt licensing
If we dig deep enough we find there are some issues with Qt.
Issue 1. Popularity is Relatively Small
Issue 2. UX
UX requirements for different platforms are different. Even though QML allows cross-platform development, most prefer native implementations on Android or iOS. In the majority of cases, Qt does its own painting. That is why an application that is made with Qt doesn’t look like a native app. For example, on Mac machines, split bars are thick, buttons are small and rounded with icons. On Windows machines, split bars are typically narrow, and buttons are more textual, with a more square design.
Issue 3. Complicated Build Process
Qt requires a separate compilation step. It makes the build process much more complicated when compared with most other libraries. As a result, C++ IDEs and tools may not understand Qt’s specifics and can flag some Qt expressions as errors. This almost forces use of QtCreator or a text only editor like VIM.
Issue 4. Challenges with Mobile Development
Qt/QML is still not mature enough for Android/iOS. It could be a problem to work with BlueTooth or native controls. That is why very easy to reinvent the wheel if you write under mobile. There are several major issues for using Qt for Android:
- Poor community (only 433 repositories of “Qt Android” on the GitHub);
- Support of NDK is poor (if you compare it with SDK for example);
- Known issues with the implementation of some specific tasks (like QtQuick.Dialogs does not work or WebKit is not supported);
- Prejudice about “native applications work better”;
- Development is more complex than on Java for Android.
Not Qt Problems
Sometimes Qt is used in strange ways that can cancel out many of the benefits. A few examples:
- Writing your own container classes (unless there are some special requirements).
- Not following Qt best practices: Qt has a number of best practices that will improve the quality of your code and make it easier for others to work with. When Using Qt is Optimal Optimal
When Using Qt is Optimal
A good example of an optimal use of Qt is a desktop project with its mobile versions. Qt is the best choice if an application should work in the same way on different platforms and it is O.K. to sacrifice a little of exact matching on the GUI. Also, it is not a problem to extend a desktop+mobile project by mobile-only versions. We follow such practices and find them to be effective.
On the other hand, it is sometimes better to develop mobile projects using native tools. Even if the project is designed for Android and iOS it is better to develop it as two different sub-projects. It is more expensive but the final output will be worth it. However, it is not dogma and in some cases, cross-platform mobile development is the optimal choice.
Images are used in this article: