Nils Christian Roscher-Nielsen

Introducing the Qt Lite project—Qt for any platform, any thing, any size

Published Thursday August 18th, 2016
29 Comments on Introducing the Qt Lite project—Qt for any platform, any thing, any size
Posted in Biz Circuit & Dev Loop

We believe in a future of great software and hardware, developed together, delivered quickly, and that you can have fun in the process. Embedded development should be just as simple as all other software development, and you should immediately see the result of your ideas running on your device.

The amount of devices and things surrounding us are rapidly increasing, becoming more intelligent and requiring software that runs on a greater variety of hardware—everything from IoT devices with or without a screen, smart watches through to high end smart TVs and industrial grade PCs. As the requirements and the world of software development is changing so does Qt. We have taken action and are now unveiling the Qt Lite Project. This is a whole range of changes to Qt, allowing you to strip Qt down and bring in exactly what you need in order to create your device for more or less any platform and any thing – regardless of size. Qt Lite is neither a separate product nor a fork of Qt—it is all built into Qt allowing us to efficiently develop and maintain it as part of the whole Qt framework. As such, many of these changes will benefit all Qt users, but especially those targeting resource-constrained devices.

For the past 20 years, Qt has been used on a massively wide range of operating systems and embedded devices. It didn’t take long before embedded Linux was as important for Qt as its desktop counterpart, but many other embedded operating systems have also followed this trend, and Qt has supported a wide range of Linux, Microsoft and various real time operating systems (RTOS).

However, to efficiently utilize Qt on these operating systems, and especially on those embedded devices—special as they often are—it has sometimes been challenging and time consuming to configure Qt to efficiently use the different hardware components, available libraries, and strip out the parts of Qt and the OS that are not needed.

Over the past six months we have looked at many of these challenges—and more—and been working on making Qt a much more targeted framework that will facilitate the whole development cycle and lifetime of embedded device based products. In this blog post we will look at some of the changes, we have made as well as the path beyond that. All of these efforts are part of “Project Qt Lite”.

The configuration system

We know that Qt is being used in many different projects, varying industries and for vastly different purposes. So making one change, or one optimal version of Qt is not feasible. Therefore the starting point, and the biggest code change coming as a part of our embedded effort for Qt 5.8, is a new configuration system. When we introduced Qt 5, we had a lot of focus on the modularization of Qt, so it was less monolithic. The modules became less dependent on each other, could easily be developed, tested and deployed independently. But configuring the content of each module was still difficult, so optimizing for a resource-constrained embedded system was not as straight forward as we would like it to be. If you needed a specific feature, like a specific way of handling internationalization or audio functionality, or broader multimedia features, you often needed to add in several new modules, where you would only use a fraction of the functionality. Enabling one single feature exclusively required a lot of manual tweaking, and that took a lot of time.

The new configuration system in Qt, allows your define the content you need from each module in much more detail for your project and easily allows for feature based tailoring of the Qt modules. We are starting with enabling this fully for Qt Core, Qt Network, Qt GUI, Qt QML and Qt Quick. You can now fine tune which features from these modules you want to include in your project. There is no longer any need to include unnecessary features. We will also expand this to be more granular and cover more modules in the time to come.

Developer Workflow

Moving forwards we want to put focus on a development workflow that has optimization in mind from the very beginning. In a world where hardware is getting cheaper, most frameworks do not care much for footprint or memory consumption — all libraries are included from the get go, all features enabled and options checked. This makes feature development simple, but optimization so much harder. Qt Lite now allows you to start with a minimal deployable configuration, and allows you to simply add in any additional feature you will require while developing your project.

This leaves you in complete control, with a continuous understanding of the consequences of your actions, and allows for transparency of the development project throughout the team. How big is the application developed becoming? Is this web browser really needed? And do cutting these corners actually make sense? Every included feature and added module will be immediately visible, and you will know how it affects the overall footprint of the application.

To facilitate this, we will start by provide two different reference configurations as a part of Qt Lite:

Firstly, a full prototyping environment, like for example the configuration behind our demo images as they are shipped with Qt for Device Creation today. This is a great starting point for a mid-cost, low volume distribution for example, it has all features enabled and can quickly and easily be used in products.

In addition to that we also want to add another Qt configuration that is as minimal as possible. This will provide a great starting point for software that needs a smaller footprint, high performance and still be delivered quickly to the market. By significantly reducing the time spent on optimization at the end of the project, products can have a much faster time-to-market.

No Open GL Requirement

One of the main drivers behind the Qt Quick and QML technology, was to introduce a rendering architecture optimized for OpenGL. However, that also meant that OpenGL became a requirement for all Qt Quick based projects. For several good reasons, we see the need for cheaper, more efficient or specially certified hardware that does not support OpenGL. In Qt we have therefore introduced a fully integrated, supported and efficient 2D Software Renderer for Qt Quick. This allows you to use all the power of the QML language to create beautiful user interfaces on embedded devices without OpenGL hardware available.

The Qt Quick 2D renderer can work in software only, but it is also designed to utilize accelerated 2D operations, for devices that packs a little bit more punch, but still doesn’t have full OpenGL support.

Tooling

Along with the new configuration system, we have also developed a new graphical tool for configuring, selecting and setting various options when building Qt. These configurations can be saved and reused. This will also make it easier to modify your configurations for new hardware, or changing requirements.

The Qt configuration tooling is now even more powerful and feature rich than ever before. By making all the options available easily accessible, integrating the documentation and providing reasonable starting default configurations for various use cases, you get a simple and efficient way to squeeze a lot more juice out of your existing projects.

We are currently working on a way to sort configuration options into groups, so that you can easily see which configurations need to work together to enable use cases like internationlization, multimedia, web capabilities or other features. You can of course save these configurations and profiles, to continue using with other builds, version so of Qt, or new hardware. These tools will be integrated as a part of Qt for Device Creation.

Targets

A major part of our focus, is on extending the available hardware that you can easily and efficiently use to deploy Qt based applications. There are several devices and project types that can benefit from our current efforts. A typical example can be devices with RAM and Flash in the 32MB or even 16 MB area, with the intention to go much lower in the future. Also, there is no longer any need for OpenGL hardware to use Qt Quick, which extends the number of devices where Qt can be used significantly.

The main usage of this is still expected to the be Cortex A based architecture, or similar, but we are also aiming at the ARM Cortex M7, as one example.

And the list goes on

There is a myriad of other features all enhancing the embedded developer experience and device creation workflow on resource-constrained devices, coming with Qt 5.8. We are further developing the Qt Quick Controls 2, that are specially designed for touch-enabled devices, and are introducing many new features as well as improvements and new themes.

We have put a lot of effort into our new Over-the-Air update mechanism. It is also a part of Qt for Device Creation for Qt 5.8, and we have already blogged about it in great detail. This is a part of our continuous push to make device creator’s life simpler, shorten time-to-market, and reduce the total cost of a project, by providing an extremely powerful way of managing your device life cycle.

The Qt Wayland based compositor makes it simple to create fully fledged multi applications devices. But we are also improving EGLFS, and enhancing the multi-screen capabilities.

And the Qt Emulator that ships with Qt Creator makes it very simple to quickly iterate over designs and optimize applications, even without the target hardware available to all developers in the project.

An open road ahead

We have for a long time been putting a lot of emphasis on the embedded space, for example with our Qt for Device Creation product, and we will continue this effort relentlessly. And we don’t want that effort just to be an internal project, but we want you to know about it. Because it is all about you, and what you can achieve when creating your products. Our aim is to improve Qt, making it more light weight, easier to use, and performing better than ever before. To achieve this, we need your feedback.

We will continue our work making Qt a better framework for embedded projects of all kinds, running on devices in a wide range of industries. We have many exciting plans and we are working with some really interesting customers to bring great projects to the market. Examples being the Automotive systems based on Qt, the usage in the Avionics industry and the work we do with home appliances amongst many other Qt based projects. IoT is another important part of our strategy ahead, and making sure that all devices can be developed with a Qt based platform, communicate over supported protocols and that software can easily be extended to the next generation device is extremely important in a wide range of industries today.

The next stage of Qt Lite—as soon as the essentials are in place—will be along three major lines.

Firstly, code optimizations to improve the run time performance and the RAM consumption. This will require a lot of code changes, in many different places of Qt. Some of these changes might not be fully source compatible with Qt, but believe that such embedded projects can make that sacrifice for the sake of performance. This is important—but difficult—work, and some of our best developers are on it.

Secondly we will spend a lot of time on the configuration of the full stack, not just the Qt libraries. With Qt for Device Creation we offer an out-of-the-box embedded Linux stack based on Yocto. We will also extend the new configuration system to cover and optimize the complete Linux stack as well as the Qt build. This will allow you to easily and efficiently improve the total footprint, boot time and complexity of your system, not just the Qt bits.

The third avenue of improvement will be to more fully integrate all the tooling around this, to bring all the elements into the same tool, and integrate this into Qt Creator. We think this can improve not only the developer experience, but also the communication in the whole team, provide more transparency towards other stakeholders and reduce the total time/cost of a project.

In summary, we have now laid the foundation of how to more efficiently address embedded development, and how to make the most of resource-constrained hardware. A configuration architecture that makes it simpler to build Qt according to your needs, and improves the performance on resource-constrained devices. We have improved Qt a lot. But we have also staked out on a clear path towards further improvements. The focus forwards will be on making Qt even faster, smaller and easier to work with. We are very much looking forwards to your feedback and feature requests, and hope all your projects are successful. If you are interested in participating in that future, to provide feedback or learn more about this, both our CTO Lars Knoll and myself will be talking about this subject at the Qt World Summit in San Francisco, October 18-20. We are looking forwards to seeing you there, and gaining your feedback!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Biz Circuit & Dev Loop

29 comments

arturo182 says:

Qt on Cortex M7? Dreams do come true!

Nils Christian Roscher-Nielsen Nils Christian Roscher-Nielsen says:

Yes, we are still not fully there in terms of stripping the Qt size down, for most M7 based boards, as they are packing very little memory. But tells us which SoC you want to use, and let’s see what we can do!

arturo182 says:

The mcu I had in mind was STM32F746NGH6, there is a 32F746GDISCOVERY dev kit available for it.
It has 1 Mbytes of flash and 340 Kbytes of RAM.

If the internal flash is not enough the chip can also execute code from external flash and RAM.

Ilyes says:

The STM32F769DISCOVERY board (http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f769idiscovery.html) also packs a lot of punch, in terms of display and h/w acceleration (e.g. Blitter and h/w JPEG decoder, plus 8M external SDRAM).

SCOTT BRADY says:

Are there any limitations as they pertain to LGPL and Commercial licences?

Nils Christian Roscher-Nielsen Nils Christian Roscher-Nielsen says:

Yes. Most of the work we do will be available also in the open source version of Qt, as it is a major part of the framework development in itself.
At least for now, the configuration tooling will be a part of the Qt for Device Creation product, and not open source.
But finding this balance is a part of the roadmap work we are inviting both customers and the larger community to take part in.

Andriy Gerasika says:

Right now minimal size of QtQuick/Qml application is >30MB on iOS. Application developers need to have a GUI tool to perform custom build of Qt w/ tons and tons of various options to reduce size of an app.

Custom linux builder/software renderer can be part of “Device Creation” package.

Please don’t include sweet features everyone can use into “Device Creation” package only. You have already forced a lot of people out of “Indie” license into “AppDev” license. “AppDev” users deserve to have GUI configuration tool for performing custom Qt builds.

Alex Libman says:

Qt is not viable until it changes to a Copyfree license.

Ivan says:

Same applies for all GPL libraries in the world? 🙂

Mouli Peer says:

Any plans on modernizing Qt at the same time with this effort? I.e. making more things native C++11 and higher, getting rid of ancient cruft, using smartpointers where appropriate, replacing Qt classes with STL classes, etc…

And getting minimal size of mobile apps down would be great.

Please don’t put this stuff in Device Creation. It would be nice if Qt was more friendly towards indie mobile apps developer that don’t have much money and just try to do something commercial as a side project 🙁

BaCaRoZzo says:

That has been stated a lot of time: up until Qt 5.7 compatibility was maintained with compilers which were not fully C++11-compliant. Hence using C++11 in Qt codebase was a big no-no (wich some exceptions). Since Qt 5.7 C++11 is fully allowed in Qt codebase. Also, using STL has been recently discussed and could happen at a certain time in the near future.

All of this is related to Qt codebase on its own and hence not related to any specific commercial license.

Mouli Peer says:

Well that doesn’t really answer anything.

“C++11 is allowed from 5.8 onwards” is not at all the same as modernizing the code base and the things I mentioned…

Also it’s perfectly clear that these changes are not related to the commercial licence.
What I meant with “this stuff” was the things in this blog post! (which mainly seem to be in DevCreation…).

BaCaRoZzo says:

AFAIK the modulatization tool was presented by Qt maintainer to the developer list as something not directly related to the dev creation. That presentation was quite technical and it is available in the developer list. Maybe they have changed their mind? Can’t tell about that.

“is not at all the same as modernizing the code base and the things I mentioned”

What I was trying to saying is that there is an ongoing effort to embrace as much C++11 as possible (e.g. using std::atomic where available, replacing Qt pointer with std pointers, really consider the adoption of STL containers…) in Qt Core since a long time now. Again, the developer list is reach of interesting discussion about this topic.

While I agree on the importance of improving the current codebase and reducing app size (from your previous post), to me the lack of mobile features is highest drawback of Qt ecosystem. Notification, ad-integration and so on. But, that’s an totally different thing. :-/

Scorp1us says:

I think this is a step in the wrong direction. Asymptoticly, memory increases and halves in price every few years (commodity markets don’t obey moores law as tightly), so I expect this to be of diminishing value. You’ll never be able to run on an $5 Arduino, but you can run on a $5 RaspberryPi.

Second, I don’t want to mess with a GUI configuration tool. Instead, I’d have a source code scanner that produces the list of what needs to be included, and have it update the config when you run qmake. I think we need more intelligence in tools, not more tools. Maybe if you have some data driven class factory you need to include more than the scanner will pick up, so you’ll need to list it out manually, but that should be the exception not the rule.

Finally, for compiling, will Qt move to a module import based directives? It seems like a logical completion of the idea to me.

BartekBl says:

I disagree. Yes, memory does get bigger and cheaper, but also Qt gets more and more features that use up this memory. If you want to address cheaper devices you can stop your progress and wait few years, but I don’t think anyone can afford to do that. The better way is to reduce memory footprint per feature and/or allow finer control over which features are enabled. And that is exactly what Qt people are doing.

Also I don’t think automatic scanner is a good idea. One simple line of little importance can cause your project to unnecessarily include whole new module. Real life example: I use xml stream reader while my colleague uses xml DOM reader. It doesn’t matter now because all Qt libraries are included anyway. But with automatic scanner you propose it would introduce unnecessary bloat as two xml libraries would be included. Manual control allows project leader to unify the way his underlings do things.
To put it another way: every time you introduce new dependency you have at least three choices: include new module, implement the feature different way or do away without that feature. Automatic tool will always default to the first option.

salt says:

Qt submodules still can’t be installed outside of qtbase’s PREFIX with qmake’s generated makefiles, yet lets make the build system more complicated. Great job guys!

Burkhard Stubert says:

Qt Lite running on a Cortex M7 suggests that an MMU won’t be required any more. How will Qt Lite work around the missing MMU? Will ucLinux be supported out of the box?

Danny says:

This is a good step forward but seems embedded/mobile device centric.

I would like to see Qt split into different editions, as opposed to this monstrous ‘tries-to-do-everything-and-run-on-everything’ framework we have right now.

In particular, a widgets only version that simply provides the widgets toolkit. This is what most developers use Qt for after all, at least on the desktop.

Qt provides modules for so many things, most of which are outdated or inferior to dedicated open source alternatives (XML, SQL etc). And QML is steadily creeping into more and more of the framework.

Why for example, does Qt ship with 3D modules (3DInput, 3DLogic etc) when any serious application making use of Qt will be using OpenGL/GLSL? Using Qt’s encapsulations for these things only makes things more complicated in the long run, especially with the bugs.

Then we have things like QtPositioning and QtSensors which are of little use on the desktop but are part of the main package anyway?

As someone who has to maintain and build multiple versions of Qt (including Qt4), for multiple platforms – 90% of which we don’t and will never use – it would be nice if Qt could be broken up into the core features that made it a success on the desktop in the first place.

Archqt says:

Hi,
yes i agree one argument is to be able to have small executable. One good thing will be to have a tool that only put things use. If we don’t use QML, if we don’t use all methods of string…
I agree that on Desktop it is not so important but on mobile it is important to have a small executable.
Sincerely

Nils Christian Roscher-Nielsen Nils Christian Roscher-Nielsen says:

Thanks for this feedback.

Yes, as I said this is embedded device centric. We have a lot of other efforts for other segments, but this is an outline of the stuff we want to do for low-performance devices.

Breaking Qt into multiple frameworks or editions is an idea, but is something that requires far more work on our side than the benefit it provides our customers. It would significantly slow down the speed of releases and bug fixes. We rather want to focus on making it possible to easily build Qt in different ways for different purposes, and now we start to make that even simpler.

I appreciate your interest in a “core” framework, but what is seen as core varies surprisingly much, and for many teams this change would unfortunately not reduce the amount of work. But further specific suggestions for improvements to the module architecture and configuration systems are much appreciated.

Danny says:

I tried to reply to this comment multiple times but it failed with the following:

“The blog.qt.io page isn’t working

blog.qt.io is currently unable to handle this request.
HTTP ERROR 500”

RayG says:

Move in the right direction. Current mobile app sizes are insane…

BartekBl says:

I have said this earlier and I will repeat it here. One thing I find most needed is control over resources – especially the memory. I’d like to be able to get away without dynamic memory allocation in traditional sense (that is general-purpose memory allocation like new or malloc). Instead I find it desirable to provide a set of predefined memory pools for Qt to use. Such manual allocation may be suboptimal, but many automotive devices must give hard guarantees like “it can support up to 1000 entries, each 1024 characters long”. It doesn’t matter that most of those entries will be empty most of the time.

Scorp1us says:

You can of course statically allocate almost everything in Qt. The QML stuff with V4, I do not know about the internals, but the pre QML stuff it can be done. It’s obtuse, but possible.

Danny says:

Qt is completely unsuited to that kind of application. The parent-child dynamic memory allocation model is hard baked into virtually every non trivial class.

Abdelghani Ouchabane says:

My company is using the enterprise 5.6 LTS, is it planned to have the Qt Lite project in this release?

Thanks

Nils Christian Roscher-Nielsen Nils Christian Roscher-Nielsen says:

No, these changes are too big to be supported in QT 5.6. It will be released with Qt 5.8, and improve and mature over the next few QT releases, also towards the next LTS release.

Ivan says:

Not the QuickTime player!

shalini says:

Your post is really good. Thank you for taking time to provide us some of the useful and exclusive information with us. Keep on blogging!

Commenting closed.

Get started today with Qt Download now