Current roadmap of Qt
What to expect from Qt in future. Short overview of the current roadmap.
Most of this information was already published in the blog. And the list of changes in the upcoming Qt 5.9 is available on the wiki.
So, here’s how the old roadmap looked like:
Except for the Qt Quick Compiler by the 5.8 release everything was implemented just as planned. And here’s a new roadmap:
If you want to influence the roadmap of Qt, submit new feature-request or change the way some component is evolving - you can do it. Just create a new task on the bugtracker (or vote for the existing one), and it will be considered by the development team (and if you are a commercial customer, it will be considered in a more thorough way):
And now some notes / additional info for the roadmap.
There are two (three) products available at the moment: Application Development and Device Creation. And there is also Automotive Suite that has almost joined them.
Beside that, an offering for industrial automation is being created right now (Industry 4.0, smart factory, machine-to-machine communication), and also possibly a separate product for STB will appear at some point.
An application store, if you wish. But instead of applications there will be libraries and plugins. Like the NuGet for Visual Studio.
There is no any concrete information, everything is under discussion, but the idea is to allow anyone to publish their plugin/library to this “Qt Store” - like, an implementation of the [KNX](https://en.wikipedia.org/wiki/KNX_(standard) protocol - and then any user (developer/company) can purchase it and use in his project.
Everything that is going to be published to the store would first go through the approval procedure checking for compatibility with Qt (and some other checks) - to make it easier for the end-user to actually “use” this plugin or library. After the purchase company-developer will get its share from the transaction, and The Qt Company will also get some commission.
Graphics and GUI
Cache for OpenGL shaders, allowing to considerably reduce the time of its initialization. After the first launch of an application the consequent launches will happen faster. This applies even to drivers with their own implementation of shader cache (but not that much, of course).
There is also some work ongoing for implementing a shared usage of such resources as bitmaps (images) in order to reduce the RAM consumption in multi-process systems. That will speed-up the launch time of applications and, well, reduce the RAM consumption.
Ability to use not only OpenGL, but some other graphical backends, like Vulkan. Specifically in Qt 5.9 there will be an OpenVG support introduced, that will allow Qt Quick applications to work on platforms without OpenGL support, but supporting OpenVG - however, like in case with 2D Renderer, not everything will be available (for example, particles and some effects).
Not exciting news for Qt Widgets. They are considered to be a “matured” technology and also not really suitable for embedded platforms (which are the priority now), so Qt Quick remains to be in focus and will get all the new stuff. However, it doesn’t mean that Widgets will be abandoned - they will still get fixes and improvements, just without any new features. But there are some discussions on the subject.
Renewed Qt Quick Compiler integration is still ongoing. Next thing to happen - ahead-of-time cache generation in addition to already implemented caching mechanism. According to the plan, Qt Quick Compiler should have been “dissolved” by the version 5.8(9) already, but not everything went according to the plan, so commercial users still have this advantage over the Open Source users (because Qt Quick Compiler is not available under Open Source license).
New elements for Qt Quick Controls:
- long-time promised TableView;
- editable ComboBox;
- multi-touch support.
Improvements in QML engine. Most noticeable - reworked garbage collector, improving performance and reducing RAM usage by Qt Quick applications.
Path rendering in Qt Quick. That will enable declarative creation of complex shapes out of lines and curves using hardware accelerated QML, which will give a significant performance boost. There will be also vendor-specific extensions (e.g. for NVIDIA).
Recently announced WebGL streaming will allow to use a web-browser (or another Qt application) as a “remote display” for the device that will “stream” its GUI over the network.
In case with web-browser everything will work without the need of pre-installing anything on the client (desktop, tablet, phone) - the browser only needs to support WebGL.
Input from mouse/keyboard will be transfered back to the Qt application on the device:
This scenario is especially relevant for devices without display, and also for those that are placed in hardly accessible places, like in a super-far-away storage, or on the 127th floor, or even somewhere under the water.
Several directions of development:
- using Qt Quick elements as 2D textures in a 3D scene;
- mesh morphing;
- improving particles and animations (with import of COLLADA animations);
- improved support for external editors and formats (models and materials import);
- further improvements in saving/loading 3D scene and introspection API;
Qt 3D Studio
Quite often we have questions about tools for designers, especially tools for creating 3D interfaces - weird enough, but turns out, this thing is in quite demand, and most requests are coming from automotive industry (3D for IVI and IC) and home appliance (coffee machines, “smart” fridges, etc).
Before we only had Qt Designer (which strictly speaking, is not really suitable for designers) and import from Photoshop via PNG Express (by the way, there will be something new for importing from external editors, but there is no much information about that yet).
But now, as it was announced, NVIDIA contributed its product NVIDIA DRIVE Design Studio to The Qt Project. And it is exactly a tool for creating a 3D GUI and it is supposed to be used by designers (technical artists).
NVIDIA decided that it will be better that way, because they have encountered some trust issues on the market, if I can say it like that. I mean, using their product implied that the user would be “locked” on NVIDIA, because the result would work only on NVIDIA’s hardware, And The Qt Company will “free” the product from this “limitation”, and this is already in process, and the first not-NVIDIA device supported should be a Raspberry Pi. So, it’s not just changing the name and logo - it is indeed a second life of the tool.
There are also plans for as tight as possible integration with existing Qt 3D framework, interaction via QML and other improvements/features.
It is planned to release a first public beta version somewhere in the second half of 2017. The release version is going to appear in 2018.
Experimental UI controls set
So-called native common controls. For the moment it is just an experiment for implementing a universal set of “native” UI controls that will look look naturally on all supported platforms.
Will it become something more that just an experiment - that’s unknown. How will it live with already existing Qt Quick Controls - that’s unknown too.
More referenced devices to come, meaning more pre-built Boot to Qt images and toolchains available.
Further development and optimizations for so-called “Qt Lite” - which actually means reconfigurability, modularization and reducing the RAM usage, allowing to target the hardware for wearables.
One more thing here is QDB - Qt Debug Bridge - a replacement for ADB. After all, it’s not cool to depend on any 3rd party tools, and there is some functionality missing anyway, so why not to implement our own.
- looking on how Qt Quick Designer is being used (it simply isn’t), it was decided to combine code mode and design mode;
- updated support for RTOS [INTEGRITY](https://en.wikipedia.org/wiki/Integrity_(operating_system);
- more Apple platforms supported: tvOS and watchOS;
- replacing MinGW with Clang on Windows. But that is so not decided yet - it’s not even on the roadmap;
- debugging for QJSEngine. The intention is to have a design that allows developers to write scriptable applications where scripts run in other threads, not the Qt GUI thread, so they could be debugged using dedicated Qt APIs. But this, again, is a quite distant possibility, no concrete plans for that.
…And one more thing: The Qt Company is actively hiring right now, there are at least 100 open positions to fill this year, and it’s not only developers positions. If you are interested, I can provide some more information / guide you to the right person / team.
Zuck: Just ask
Zuck: I have over 4,000 emails, pictures, addresses, SNS
smb: What? How'd you manage that one?
Zuck: People just submitted it.
Zuck: I don't know why.
Zuck: They "trust me"
Zuck: Dumb fucks