KookBook 0.2.0 available – now manage your cooking recipes better

I got a bit traction on KookBook and decided to fix a few bugs, mostly in the touch client, and add some features.

Get it here: kookbook-0.2.0.tar.xz

KookBook is now also available in Debian, thanks to Stuart Prescott

KRecipe converter
Some people has a large recipe collection in KRecipe and would like to try out KookBook. I wrote a convertion python script now available. It works in “current directory” and reads the krecipe database from there and outputs KookBook markdown files in same repository. It has so far been tried on 1 database.

Bug fixes

  • Fix install of touch client
  • Fixes in desktop files
  • Fixes in touch client’s file open dialog
  • Touch client now show images in recipes
  • You could end up with no dock widgets and no toolbar and no way to recover in the desktop client. This is now fixed
  • Build fixes

Some people have started talking about maybe translation of the interface. I might look into that in the future.

And I wouldn’t be sad if some icon artists provided me with a icon slightly better than the knife I drew. Feel free to contact me if that’s the case.

Happy kooking!

Release 2.18.3: QML JSON ListModel and Todo List App

V-Play 2.18.3 adds the JsonListModel as a performant and feature-rich QML ListModel enhancement for Qt. It helps you transform your JSON data to a model and enables you to detect changes to individual items in your model. You can then only update the changed items in your UI instead of updating the full list. This update also adds several improvements and fixes.

Improved Data Manipulation and ListView Performance

You can now use JsonListModel to transform your JSON data into a QML ListModel for usage with e.g. an AppListView.

The JsonListModel type implements the full QML ListModel API and fires individual events for all changes in the data. The list view can thus only update relevant entries or apply transition animations. This is super useful, as you can e.g. fetch new data and simply replace the old JSON. The JsonListModel will detect all changes, and the ListView updates its items accordingly – without a full redraw.

You thus get much better performance and scrolling stays smooth when the list is updated:


The JsonListModel is backed by a performant QSyncable model in Qt C++ and exposed to QML for easy usage. With the JsonListModel you can:

  • Fetch JSON data from REST APIs with QML and JavaScript.
  • Pass the data to your C++ list model, which synchronizes the JSON data and prepares it for usage in your view.
  • Show the model data with a list view in QML, which only renders list items that have changed.

With the JsonListModel you do not require to implement a custom model in C++ anymore. The JsonListModel itself is your C++ model, which is fully usable from QML and can work with JSON list items of any format.


Apart from list views, the model also supports the GridView and Repeater types to display model data.

The following example shows how to use JsonListModel together with AppListView. When adding a new item to the JSON, the JsonListModel detects the change. The AppListView can thus use a transition animation when adding the entry. It is not required to fully redraw the list and existing items in the view are not affected.

import VPlayApps 1.0
import QtQuick 2.0

App {
  NavigationStack {
    Page {
      id: page
      title: "JSONListModel"

      // property with json data
      property var jsonData: [
          "id": 1,
          "title": "Entry 1"
          "id": 2,
          "title": "Entry 2"
          "id": 3,
          "title": "Entry 3"

      // list model for json data
      JsonListModel {
        id: jsonModel
        source: page.jsonData
        keyField: "id"

      // list view
      AppListView {
        anchors.fill: parent
        model: jsonModel
        delegate: SimpleRow {
          text: model.title

        // transition animation for adding items
        add: Transition {
          NumberAnimation {
            property: "opacity";
            from: 0;
            to: 1;
            duration: 1000
            easing.type: Easing.OutQuad;

      // Button to add a new entry
      AppButton {
        anchors.horizontalCenter: parent.horizontalCenter
        anchors.bottom: parent.bottom

        text: "Add Entry"
        onClicked: {
          var newItem = {
            "id": jsonModel.count + 1,
            "title": "Entry "+(jsonModel.count + 1)

          // manually emit signal that jsonData property changed
          // JsonListModel thus synchronizes the list with the new jsonData
    } // Page


Please see the documentation of JsonListModel for more information and examples. The JsonListModel is now also used for all JSON models of the V-Play SDK app demos.

New App Example with Core App Components

You can find a new app demo which incorporates all core elements that you need in a basic app. It is based on the principles of the Separation of Model, View and Logic Code guide. The demo includes login, app navigation, controls, REST API access, offline caching and also uses the JsonListModel.


You can find the Basic Demo App along with other app demos in the V-Play SDK and as a project wizard in Qt Creator. The basic app is the best starting point for new applications and combines many features that used to be part of individual wizards before. It is also available for you on GitHub.

Todo List App with Sort and Filter Options

To further demonstrate the power of JsonListModel, we also prepared an advanced Todo List Demo App.


It uses list transition animations and shows how to integrate PullToRefreshHandler, VisibilityRefreshHandler or SortFilterProxyModel. The demo supports fetching of todos, creation and storing of drafts, offline caching, paging, sorting and filtering.

Use Custom Page Transitions

You can now configure the used NavigationStack page transition with NavigationStack::transitionDelegate property. By default, the NavigationStack uses NavigationStack::transitionDelegateiOS on iOS and NavigationStack::transitionDelegateAndroid on Android.

You can also specify a custom transition using StackViewDelegate.

More Features, Improvements and Fixes

Here is a compressed list of further improvements with this update:

For a list of additional fixes, please check out the changelog.

How to Update V-Play

Test out these new features by following these steps:

  • Open the V-Play SDK Maintenance Tool in your V-Play SDK directory.
  • Choose “Update components” and finish the update process to get this release as described in the V-Play Update Guide.

V-Play Update in Maintenance Tool

If you haven’t installed V-Play yet, you can do so now with the latest installer from here. Now you can explore all of the new features included in this release!

For a full list of improvements and fixes to V-Play in this update, please check out the change log!




More Posts Like This


Machine Learning: Add Image Classification for iOS and Android with Qt and TensorFlow

Qt AR: Why and How to Add Augmented Reality to Your Mobile App
Qt AR: Why and How to Add Augmented Reality to Your Mobile App

v-play-2-18-2-mvc-mvvm-flux-guide-qt-creator-4-7Release 2.18.2: Guide for MVC, MVVM, Flux with QML

Release 2.18.1: Use JavaScript Promises with Qt, Material Cards and an Improved API to Connect to REST Services

Release 2.18.0: Update to Qt 5.11.1 with QML Compiler and Massive Performance Improvements

How to Make Cross-Platform Mobile Apps with Qt – V-Play Apps

The post Release 2.18.3: QML JSON ListModel and Todo List App appeared first on V-Play Engine.

Qt Creator 4.8.1 released

We are happy to announce the release of Qt Creator 4.8.1!

This release contains fixes for:

  • wrong background color being used for some text highlighting items
  • Qt Creator sometimes crashing when renaming a file in the file system view
  • the Clang code model back-end crashing when the bugprone-suspicious-missing-comma check was enabled
  • various errors occurring when parsing Boost headers
  • various issues arising with the debugger integration
  • the ANDROID_NDK_PLATFORM being wrong and debugging having issues on Android ARMv8
  • Qt Creator sometimes crashing when attempting to detect Android toolchain ABIs

To name some of them. Find out more in our change log!

Get Qt Creator 4.8.1

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.8.1 is also available through an update in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.8.1 released appeared first on Qt Blog.

Qt Customer Survey 2018

The perpetual wheel of time turns, and 2018 is part of the past. For those of us not fortunate enough to have access to a DeLorean – fully equipped with Flux capacitor and a 1,21 GW power source – it is impossible to commit changes to this archived branch of time. What we can do, is to do a retrospect on 2018 and use the gained knowledge to improve during 2019. We are fortunate enough to have a lot of feedback provided by you in our 2018 Customer Survey, and it is about time we share some of the results with all of you.

Where’s Qt used?

Not surprisingly, Qt is still used in the same markets and industries as previous years, i.e. enterprise applications, game development tools, robotics, smart homes and factories, test and measurement systems, consumer goods, automotive, healthcare and medical equipment, security systems, digital TVs, aerospace and so much more. We know that Qt is used by some of the largest space agencies, but we still can’t confirm that Qt is in orbit or on its way to distant planets (I wanted to write galaxies, but that will most likely remain a dream for generations still).

Windows is by far the most common deployment platform, closely followed by a combination of Linux varieties and macOS. Deployment to Embedded Linux has increased with almost 10%, which confirms that the use of Qt in embedded devices is increasing. The fact that 20% deploys to mobile platforms (Android and iOS) is a good indication that we need to bring some more hay to those horses.

Technology and tools

User interface creation is one of the largest use-cases for Qt, and as such it is interesting to look at the use of the different UI technologies and how you use them. We have received a lot of feedback related to Qt Widgets, so let’s get that rabbit out of the hat first; Qt Widgets are not dead or dying. We are still putting a lot of time and effort into Qt Widgets, and that is time well spent. Even though the use of Qt Widgets is slowly declining (about 6% per year), 75% of you are still using them to create user interfaces. There will not be any radical changes to Qt Widgets, but they will remain functional and available for many years. We may even throw in a couple of new widgets we have been specifically asked for. Where the use of Qt Widgets slowly decline, the use of Qt Quick increases fast. The use has increased with 15% since 2017, and Qt Quick is now used in 2 out of 3 projects. The use-cases certainly vary depending on the target platforms; Qt Widgets are more frequently used for desktop applications and Qt Quick favoured for embedded and mobile platforms. The trend is, however, the same, the use of Qt Widgets are slowly decreasing while Qt Quick is rapidly increasing.

When it comes to tools, the short story is that the tools that were important for you in 2017, remained important in 2018. Qt Creator is still numero uno, and most of you love it. That being said, we will continue to improve Qt Creator based on provided suggestions, requests and reported bugs. Tools for debugging, profiling and static code analysis are increasingly important, and we get good feedback on these as well. There are some tools that clearly aren’t as useful and impressive, but the positive thing is that there is a good coherence between the tools you find important and the tools receiving most care and affection from our side.


Looking into customer surveys are – and should be – a humbling activity, but when it comes to the documentation it is hard to not go completely narcissistic. Close to 100% regard the documentation as a very important part of Qt, and when you get feedback like “I wish all documentation was like this” it is hard not to break out in a huge grin. A huge thanks to everyone who contributes, or has contributed to, the great piece of work Qt Documentation is.

Related to documentation are the various other forms of learning, finding information and discussing everything Qt. This particular blog post may not find a way to the stars (again dreaming of Qt, and myself, on the way to those galaxies) but in general, you find our blog posts interesting. This inspires us to continue the work and you can look forward to many useful blog posts this year. The forums are still relevant for many, but we would like to see more activity on forum.qt.io, making it even more relevant and valuable for all. Live webinars seem to be losing some of the appeal. On the other hand, recorded webinars, training videos and tutorials are in high demand. We will do our best to adjust to these trends.


It’s always important for us to learn the hows, whats, and wheres of your Qt usage, but equally (if not more) important is the feedback on your satisfaction. Every year we ask how likely it is that you will recommend Qt to a friend or colleague, rated on a scale from 0 to 10 (10 being very likely). We would have liked to see the same overwhelming feedback as for the documentation, but it gives us confidence when 35% respond with 10. If we group together 7 to 10, we have the feedback from 91,7% of you, so all in all we are pretty certain that you in general are satisfied with Qt. We know, from the survey and other channels, that there are many things and areas we can improve, and we will strive to do that in the coming weeks, months and years.

Thank you for taking the time to respond to our customer survey! This is but a brief summary of the results and the huge amount of valuable feedback received. We will continue to work with the collected data and utilise it to make Qt even better in the future.


The post Qt Customer Survey 2018 appeared first on Qt Blog.

Qt 5.12 LTS – The road to faster QML application startup

The Qt Company has been running benchmarks like QMLBench for a long time that assist us knowing when a change creates a performance regression, but it’s also important to see how Qt performs at a higher level, allowing components to interact in ways that granular tests like QMLBench can’t show. In this blog post, we’ll walk through new application startup testing results from a more real-world QML benchmark application.


The benchmark

For these tests, a relatively simple QML application was developed that utilizes many areas of QtDeclarative and QtGraphicalEffects. The application code was written as a casual developer might, and has not been designed for optimal startup, memory consumption, or performance. Because we’re benchmarking, the application does not make use of Interactive elements or user input. The application is of low complexity, without divergent logic, so that results are as consistent as possible between test runs. Though no benchmark will ever truly simulate real-world performance with user interaction, the test discussed here aims to more accurately represent a real-world QML workload than QMLBench or the QtQuickControls “Gallery” example.

QML Benchmark

The benchmark application. It combines textures, animations, QML shapes, repeaters, complex text, particle effects, and GL shaders to simulate a heavier, more real-world application than other QML benchmarks like QMLBench.

Download the benchmark source code here.

Lars has previously written about The Qt Company’s commitment to improving the performance of Qt, and with the recent release of Qt 5.12 LTS, the efforts made are really showing, especially on QML. Among the improvements, a good number have been towards improving startup performance. Out of the platforms tested, the greatest startup performance improvement was seen on the lowest power device we tested, a Toradex Apalis i.MX6. Let’s explore that.

Startup Performance


The chart above shows how the features in Qt 5.12 LTS really cut down on the startup performance, dropping time-to-first-frame from 5912ms in Qt 5.6 to only 1258ms in Qt 5.12.0, a 79% reduction! This is thanks to a number of new features that can be stacked to improve startup performance. Let’s walk through each.

  1. The Shader Cache – Introduced in Qt 5.9 LTS

    The shader cache saves compiled OpenGL shaders to disk where possible to avoid recompiling GL shaders on each execution.

    Pros: Lowers startup time and avoids application lag when a new shader is encountered if the shader is already in the cache.
    Cons: Systems with small storage can occasionally clear shader caches. If your application uses very complex shaders and runs on a low-power device where compiling the shader may produce undesirable startup times, it may be recommended to use pre-compiled shaders to avoid caching issues. There is no performance difference between cached shaders and pre-compiled shaders.
    Difficulty to adopt: None! This process is automatic and does not need to be manually implemented.

  2. Compiled QML

    Without use of the Qt Quick Compiler detailed below, QML applications built on Qt versions prior to 5.9 LTS would always be compiled at runtime on each and every run of the application. Depending on the application’s size and host’s processing capabilities, this action could lead to undesirably long load times. Two advancements in Qt now make it possible to greatly speed up the startup of complex QML applications. Both of which provide the same startup performance boost. They are:

    Qt Quick Cache – Introduced in Qt 5.9 LTS

    The Qt Quick Cache saves runtime-compiled QML to disk in a temporary location so that after the first run when qml gets compiled, it can be directly loaded on subsequent executions instead of running costly compiles every time.

    Pros: Can greatly speed up complex applications with many qml files
    Cons: If your device has a very small storage device, the operating system may clear caches automatically, leading to occasional unexpected long startup times.
    Difficulty to adopt: None! This process is automatic and does not need to be manually implemented.

    Pre-generated QML (Qt Quick Compiler) – Introduced in Qt 5.3 for commercial licensees, both commercial and open source in Qt 5.11

    The Quick Compiler allows a QML application to be packaged and shipped with pre-compiled QML. Initially available under commercial license from Qt 5.3 onwards, it is available for both commercial and open-source users from Qt 5.11 onwards.

    Pros: Using Quick Compiler has the advantage of not needing to rely on the runtime generated QML cache, so you never need to worry about a suddenly unexpected long startup time after a given application host clears its temporary files.
    Cons: None!
    Difficulty to adopt: Low. See the linked documentation. It’s often as simple as adding “qtquickcompiler” to CONFIG in your project’s .pro file!

  3. Distance Fields – Introduced in Qt 5.12 LTS

    Though Qt has been using Distance Fields in font rendering for a long time in order to have cleaner, crisper, animatable fonts, Qt 5.12 introduces a method for pre-computing the distance fields. Learn more about Distance Fields and implementation in this blog post by Eskil.

    Pros: Using pre-generated Distance Field fonts can drastically reduce start-up performance when using complex fonts like decorative Latin fonts, Chinese, Japanese, or Sanskrit. If your application uses a lot of text, multiple fonts, or complex fonts, pre-generating your distance fields can knock off a huge chunk of time to startup.
    Cons: Generated distance field font files will be marginally larger on disk than standard fonts. This can be optimized by selecting only the glyphs that will appear in your application when using the Distance Field Generator tool. Non-selected glyphs will be calculated as-needed at runtime.
    Difficulty to adopt: Low. See the linked documentation. No additional code is necessary, and generating the distance fields for you font takes seconds.

  4. Compressed textures – Introduced in Qt 5.11

    Providing OpenGL with compressed textures, ready to be uploaded to video memory right out of the gate, saves Qt from need to prepare other file types (jpg, png, etc…) for upload.

    Pros: Using compressed textures provides a faster startup time, decrease in memory usage. It may even provide a bit of performance boost depending on how heavy your texture use is, and how strong of compression you choose to utilize.
    Cons: While the compression algorithms in use for textures inherently require some tradeoff in visual fidelity, all but the most extreme compression schemes will usually not suffer any visible fidelity loss. Choosing the right compression scheme for your application’s use case is an important consideration.
    Difficult to adopt: Low +. See this blog post by Eirik for implementation details. Almost no coding is required, needing only to change texture file extensions in your qt code. Easy-to-use tools for texture compression are available, like the “texture-compressor” package for Node.



The i.MX6 is a great representation of mid-tier embedded hardware, and the performance improvements included in Qt 5.12 LTS really shine in this realm. Stack all the improvements together and you can really cut down on the startup time required in low power devices.

With these latest test results for low-power hardware, Qt 5.12 could lend a hand to your development by greatly decreasing startup times, particularly when running on low and mid-tier embedded devices. These new performance improvements are easy to adopt, requiring only the most minor of changes to your codebase, so there’s very little reason to not start using Qt 5.12 right away, especially if your project is cramming heavy QML applications into a fingernail sized SoC. The chart below is a reminder of what’s possible with Qt 5.12 LTS, and faster start-up time makes happier customers.


The post Qt 5.12 LTS – The road to faster QML application startup appeared first on Qt Blog.

Announcing the Qt Automotive Suite 5.12

We are very happy to announce the latest edition of our Qt Automotive Suite 5.12, a unified HMI toolchain and framework for building your next generation digital cockpits. It is based on Qt 5.12 and it is an LTS release as well.

In case you hear about this for the first time, Qt Automotive Suite was created to solve the key challenges in HMI creation (see https://blog.qt.io/blog/2018/06/27/introducing-qt-automotive-suite-5-11/ and https://blog.qt.io/blog/2018/02/27/introducing-qt-automotive-suite-2-0/) for digital cockpits in automobiles. With combinations of world class tooling, automotive specific software components, and highly optimized software framework for embedded devices, we are solving those challenges and offering the world’s end-to-end HMI solution with a single technology.

What’s new?

In the 5.12 release, we keep enhancing our components to evolve in following key directions:

  • Qt everywhereqt_everywhere
    Figure 1. Qt drives all screens in the digital cockpit
  • Continuously improving developer productivity
  • The power of multi-process Qt-based HMI on embedded systems
  • Paving the way for easy integration with 3rd party services

For the Qt Application Manager, we are introducing the new feature – “Intent Management” as a technology preview. Today, the concept of intents is commonly used in mobile platforms such as iOS and Android, where its primary use case is to facilitate intercommunication between apps as a service, for example voice assistants used by other apps. With our new Intent Management, it is now possible to provide and query services across applications via a communication channel. This would allow applications to publish their “intent” capabilities, thereby other apps and services such as voice assistant can query and trigger the right application for intended action. Soon you can integrate Amazon Alexa Auto or Google assistant and let them easily communicate with HMIs in the connected vehicles.

For Qt IVI, we have now created a new Simulation System which allows scripting of simulated backend service data and basic logic in QML. With that, Qt IVI can not only generate frontend and backend APIs, it also allows developers to easily write backend simulations which provide not only data but also can simulate some business logic.

We now introduced a new component called Deployment Server, formerly known as Neptune Appstore. It is a lightweight network server that hosts downloadable application packages. The main use of the Deployment Server is to allow easy system integration in larger projects with multiple teams. Teams can publish their apps, e.g. HVAC, Media, or Navigation, one by one to the deployment server and so enable quick testing of new app versions with a minimal risk and effort.

To further enhance the developer experience, we added a new template to the Project Wizard in Qt Creator which can be used to create a skeleton for an application running with Qt Application Manager.

Maximizing software reusability has always been what Qt is best known for – code once, deploy everywhere. Now we are introducing a progressive support for mobile platforms, so the HMI code developed for IVI can also be used to create OEM’s companion applications. In 5.12, we added a technical preview where developers can compile and run Neptune Reference IVI project for Android as is.

architecture_qtas_5-12Figure 2. Architecture of Qt Automotive Suite

Qt for Device Creation 5.12 LTS

Qt Automotive Suite 5.12 sits on top of Qt 5.12, bringing major new features, performance & stability improvement, and receive Long Term Support.

Qt 3D Studio & Qt Design Studio

With Qt 3D Studio 2.2, we now have improved usability and introduced new features such as supporting compressed textures and stereoscopic rendering. Have a read at Qt 3D Studio 2.2 blog. We also recently introduced a new design tool called Qt Design Studio, bringing designers and developers closer than ever for 2D and 2.5D HMI creation.

design-tool-and-software-frameworkFigure 3: Design tool and software framework under one technology

Qt Application Manager

The latest Qt Application Manager has following updates:

  • The core Application and Window management APIs have been heavily refactored to support a more QML-like, declarative approach when developing a System UI
  • The monitoring sub-system (responsible for reporting CPU/GPU load, memory consumption, etc.) was also rewritten with a new API that makes it very easy to use it from QML as well as to extend it from QML via custom “sensors”
  • Added a new sub-system called “Intents”, which provides a loosely coupled inter-application communication mechanism. Basic communication in single- as well as multi-process mode works seamlessly. More advanced features like sharing of file handles and support for background services are to be implemented
  • The shared window properties are now implemented via a custom Wayland extension instead of using Qt’s proprietary, deprecated one
  • Dynamically installed applications can now be used to update built-in applications by shadowing them
  • Because of the new window management API and the refactored code, the QML imports have been upgraded to version “2.0”

Qt Application Manager Plugin for Qt Creator

The latest Qt Application Manager Plugin for Qt Creator has following updates:

  • Added application templates for a system UI and a simple application to the “New Project” wizard
  • Added a possibility to launch a system UI as an external tool in Qt Creator. Minidesk is registered as an external tool when the Qt Installer is used


Qt IVI has received updates highlighted as follow:

  • QtIvi got extended by the QtIvi Simulation System (http://doc-snapshots.qt.io/qtivi/simulation-system.html). In previous versions a “simulation” backend needed to be created either manually or using a static autogenerated stub. The new QIviSimulationEngine provides a better flexible way to script the “simulation” in QML and use JSON as a simulation data format. Both can be overwritten at runtime to provide an easy way of testing a specific behavior. All is still integrated in the “ivigenerator” and can be autogenerated from QFace filesqt_ivi_5-12Figure 4: Qt IVI Simulation System
  • Improved integration of Python on Windows and macOS. Python is used by the code generator based on QFace
  • The python integration is now more flexible and creates a virtualenv only in situation where it is really needed. If all the needed python packages are provided by the system’s python version no virtualenv is created.
  • To improve CI integrations, a folder of pre-cached pip packages can now be provided at build time to reduce the amount of downloaded python packages.
  • With 5.12, the “ivigenerator” now also supports the autogeneration of models from QFace files. The new autogenerated models use the QIviPagingModel class as a base to provide full support of retrieving the model data from an async IPC API, see http://doc-snapshots.qt.io/qtivi/models.html

QML Live

QML Live has the following updates:

  • Focus the development of QML Live on the needs of those users who do not use Qt Design Studio
  • Introduction of project spaces with “qmllive” project files
  • Various improvements in the UI of the QML Bench

Deployment Server

Deployment Server has following updates:

  • Refactored the code to leave the status of the demo
  • Added a possibility to upload a package from command line
  • Start using tags for various checks in the queries from different clients
  • Support of checking the CPU architecture, based on tags
  • Support of checking the version information, based on tags


GammaRay has the following updates:

  • Added new inspection tool for QtLocation geo positioning data. Besides visualizing the currently provided positioning data on a map, it also allows you to override this data, either manually or via replaying an NMEA GPS log. So there’s no need to physically move around anymore when debugging location-aware applicationsgammaray_5-12Figure 5. Introspecting geo positioning data
  • Added a new centralized problem report view. While so far inspection tools that noticed an issue in the application code reported that in their own way, we now have the infrastructure to collect this in a single place, including navigation to the corresponding source code location where available. This view now also allows to scan the entire application for certain problem typesgammaray_5-12_checker
    Figure 6. Centralized problem report view
  • Added new consolidated system information view, that unifies system environment and system paths views, and can show a number of additional pieces of information about the Qt installation used by the analyzed application

Be sure to check out the GammaRay documentation as well as the blog at: https://www.kdab.com/gammaray-2-10-0-release/

Reference UI

Reference UI has received updates highlighted as follow:

  • Enabling of the use of harnesses for isolated component development and testing with the first use in the Instrument Cluster side
  • Refactored the file and folder structures for the code as well as QML imports and assets for a more modular architecture
  • RTL language support with automatic layout mirroring and translation to Arabic for parts of the UIneptune_arab
    Figure 7. RTL language support
  • Support of multiple Styles incl. a possibility to use style-specific UI components in one application code base
  • Added the LUCEE Style to be used in the new multi-style setupneptune_5-12Figure 8. A new theme
  • Make it possible to have only one Theme in a Style
  • Make “main.qml” contains siblings of windows (Center Console, Instrument Cluster and HUD)
  • Move the climate section out of the System UI into a separate application and introduce BottomBar Window
  • A new handling of a multi-display environment with the HUD window as example.
  • Able to start when the Cluster and HUD displays are not available
  • Persistency support for application widgets
  • Migrated to use the refactored Application and Window API in the Qt Application Manager
  • Migrated to use the refactored SystemMonitor API in the Qt Application Manager
  • Introduce a clearer Neptune Window API to be used by the application that aligned with Neptune Window Item API in the System UI
  • Initial reference test scripts for Squish. They are located in the folder “squishtests”.
  • Migrated component tests based on QML Test Runner and located in the folder “tests” to Qt 5.12
  • The Appstore application has been renamed to Downloads
  • Various enhancements in the provided applications and in the System UI

Comprehensive documentation

Qt Automotive Suite 5.12 comes with further improved documentation and examples for most of development needs.


With Qt Automotive Suite 5.12, we revamped the architecture behind the new Neptune 3 reference UI to further simplify the UI development. We introduced Intent Management in Qt Application Manager which enriches the multi-process pattern of Qt Automotive Suite application development with a fundamental capability of inter-application services. And we made a significant number of smaller improvements in all our software components. Once again, many thanks for the feedback especially from our customers and prospects.

The post Announcing the Qt Automotive Suite 5.12 appeared first on Qt Blog.

qsslint – A linter for Qt stylesheets

Enter the wonderful world of tools for which the announcement blog takes more time to write than the tool itself.

qsslint is a small command-line utility for verifying the syntax of your Qt stylesheet files (*.qss). It’s much like KDAB’s previous linter contribution, qmllint. It simply returns 0 if the stylesheet is valid, and non-zero otherwise.

Don’t get me wrong, I do dislike CSS and don’t want to encourage its use.But if you can’t run away from it, then at least use a linter to catch errors at compile time rather than production.

The suggested way to use these tools in your day-to-day is: you don’t. Instead, incorporate them into your build system or CI and forget about them until a developer makes a typo.

Furthermore, use the same advice for each different source file-type. Be it XML, JSON or QML, there are plenty of linters available. And finally, for C++, the compiler already checks the syntax for you, but now you can also verify Qt semantics by using clazy, or get advanced C++ diagnostics with clang-tidy.

So, what else should we do at build time ? Suggestions welcome. 🙂

The post qsslint – A linter for Qt stylesheets appeared first on KDAB.

Refactor with Clang Tooling at code::dive 2018

I delivered a talk about writing a refactoring tool with Clang Tooling at code::dive in November. It was uploaded to YouTube today:

The slides are available here and the code samples are here.

This was a fun talk to deliver as I got to demo some features which had never been seen by anyone before. For people who are already familiar with clang-tidy and clang-query, the interesting content starts about 15 minutes in. There I start to show new features in the clang-query interpreter command line.

The existing clang-query interpreter lacks many features which the replxx library provides, such as syntax highlighting and portable code completion:

It also allows scrolling through results to make a selection:

A really nice feature is value-based code-completion instead of type-based code completion. Existing code completion only completes candidates based on type-compatibility. It recognizes that a parameterCountIs() matcher can be used with a functionDecl() matcher for example. If the code completion already on the command line is sufficiently constrained so that there is only one result already, the code completion is able to complete candidates based on that one result node:

Another major problem with clang-query currently is that it is hard to know which parenthesis represents the closing of which matcher. The syntax highlighting of replxx help with this, along with a brace matching feature I wrote for it:

I’m working on upstreaming those features to replxx and Clang to make them available for everyone, but for now it is possible to experiment with some of the features on my Compiler Explorer instance on ce.steveire.com.

I wrote about the AST-Matcher and Source Location/Source Range discovery features on my blog here since delivering the talk. I also wrote about Composing AST Matchers, which was part of the tips and tricks section of the talk. Over on the Visual C++ blog, I wrote about distributing the refactoring task among computers on the network using Icecream. My blogs on that platform can be seen in the Clang category.

All of that blog content is repeated in the code::dive presentation, but some people prefer to learn from conference videos instead of blogs, so this might help the content reach a larger audience. Let me know if there is more you would like to see about clang-query!

Reducing Application Size using Link Time Optimization

We need to talk about calories! Not the calories from your Christmas cookies — those don’t count. But, calories in your Qt application. We’re going to take a look at a technique that is easy to enable and helps you save precious bytes around your application’s waistline.

The Old vs The New

Traditionally, you would build your application by letting the compiler translate your .cpp source files to machine code. The result is stored in .o object files, which we then pass over to the linker, to resolve references between the files. At this point, the linker does not change the machine code that was generated. This division of work between the compiler and the linker allows for quick development cycles. If you modify one source file, only that file gets recompiled and then the linker quickly re-assembles the application’s binary. Unfortunately, this also means that we are missing out on an opportunity to optimize.

Imagine that your application has two functions: main() in main.cpp and render() in graphics.cpp. As an experienced developer, you keep all your graphics code encapsulated in the render() function — anyone can call it from anywhere! In reality, it is only the application’s main() that calls render(). Theoretically, we could just copy and paste the code in render() into main() — inlining it. This would save the machine code instructions in main() to call render(). Once that’s done, we may even see opportunities to reuse some variables and save even more space and code. Now, if we tried to do this by hand, it would quickly escalate into Spaghetti code with lots of sauce.

Luckily, most compilers these days offer a technique that allows you apply such optimizations (and deal with the spaghetti mess) while retaining the modularity and cleanliness of your code. This is commonly called “Link Time Optimizations” or “Link Time Code Generation”. The latter describes best what really happens: Instead of compiling each source file to machine code one-by-one, we delay the code generation step until the very end — linking time. Code generation at linking time not only enables smart inlining of code, but it also allows for optimizations such as de-virtualizing methods and improved elimination of unused code.

Link Time Optimization in Qt

To enable this technique in Qt, you have to build from source. At the configure step, add -ltcg to the command line options. We thought hard, and this is the most cryptic and vowel-free name we could come up with 😉

To demonstrate the effectiveness of Link Time Code Generation, let’s look at a fresh build of the Qt 5.12 branch, compiled with GCC 7.3.0 for ARMv7 against an imx6 Boot2Qt sysroot. For analysis, we’re going to use Bloaty McBloatface (https://github.com/google/bloaty), which is a lovely size profiler for binaries. The Qt Quick Controls 2 Gallery, statically linked, serves as a sample executable. When running bloaty on it, with a regular Qt build, you’ll see output like this:

    VM SIZE                      FILE SIZE
 --------------                --------------
   0.0%       0 .debug_info      529Mi  83.2%
   0.0%       0 .debug_loc      30.4Mi   4.8%
   0.0%       0 .debug_str      18.6Mi   2.9%
   0.0%       0 .debug_line     14.2Mi   2.2%
  68.1%  13.9Mi .text           13.9Mi   2.2%
   0.0%       0 .debug_ranges   9.60Mi   1.5%
   0.0%       0 .debug_abbrev   6.29Mi   1.0%
  29.5%  6.01Mi .rodata         6.01Mi   0.9%
   0.0%       0 .strtab         3.17Mi   0.5%
   0.0%       0 .symtab         2.35Mi   0.4%
   0.0%       0 .debug_frame    1.80Mi   0.3%
   0.0%       0 .debug_aranges   485Ki   0.1%
   1.2%   249Ki .data.rel.ro     249Ki   0.0%
   0.3%  68.2Ki .ARM.extab      68.2Ki   0.0%
   0.2%  38.2Ki .bss                 0   0.0%
   0.1%  30.3Ki [25 Others]     35.4Ki   0.0%
   0.1%  30.3Ki .got            30.3Ki   0.0%
   0.1%  24.1Ki .ARM.exidx      24.1Ki   0.0%
   0.1%  15.1Ki .dynstr         15.1Ki   0.0%
   0.1%  13.6Ki .data           13.6Ki   0.0%
   0.1%  13.2Ki .dynsym         13.2Ki   0.0%
 100.0%  20.4Mi TOTAL            637Mi 100.0%


The “VM SIZE” column is what’s particularly interesting to us — it tells us how much space the different sections of the program consume when loaded into memory. Here, we see that the total cost will be ~20 MB.

Now, let’s compare that to a build with -ltcg enabled.

Comparison between regular and LTCG buildThe new VM size is at 17.3 MiB — that’s nearly a 15% reduction in cost, just by passing a parameter to configure.

This drastic gain here is because we chose a static build. However, even when you use a dynamic build, this optimization is worth it. In this case, LTCG is applied at the boundary of shared libraries.

Bloaty can show this by comparing a regular build against an LTCG-enabled build of libQt5Core.so.5.12.0:

    VM SIZE                      FILE SIZE
 --------------                --------------
 -53.8%     -28 [LOAD [RW]]          0  [ = ]
 -11.9% -1.78Ki .got           -1.78Ki -11.9%
  -0.2% -3.05Ki .rodata        -3.05Ki  -0.2%
 -10.0% -3.54Ki .rel.dyn       -3.54Ki -10.0%
 -17.2% -7.52Ki .ARM.exidx     -7.52Ki -17.2%
 -16.9% -18.4Ki .ARM.extab     -18.4Ki -16.9%
 -21.2%  -691Ki .text           -691Ki -21.2%
 -13.9%  -727Ki TOTAL           -838Ki -13.8%


The linker produced a smaller library with less code, less relocations, and a smaller read/write data section.


At this point, this seems like a win-win situation, and you may wonder: Why isn’t this enabled by default? No, it’s not because we’re stingy 😉

One issue is that in the Qt build system, currently, this is a global option. So if we were to enable this with the Qt binaries, everyone using them will be slowed down and it requires them to opt-out explicitly, in the build system. We’re working on fixing that, so that eventually, we can ship Qt with LTCG enabled, and then you can enable this at application level.

Another issue is that by delaying the code generation to link time, we are increasing the time it takes from modifying a single source file to creating a new program or library. It’s almost as if you touch every single source file every time, making it less practical for day-to-day use. But, this optimization is definitely something that fits well into the release process, when creating your final build. So, your Release Manager can use it.

The post Reducing Application Size using Link Time Optimization appeared first on Qt Blog.

TableView and Qt 5.12 / Qt Creator 4.8

I finally got around to doing the final merge for QmlBook this year.

I just merged the chapter on the brand new TableView. This let’s you show 2D data tables in an efficient way.

I also merged the version upgrade, so the text should now reflect what is available from Qt 5.12 and be based on menus and screens from Qt Creator 4.8.

During this update of the text, we took the decision not to upgrade all import statements to QtQuick 2.12. Instead, we use different versions in different places. However, the contents of Qt 5.12 is covered.

There are still two things left for the 5.12 branch. The first is to use the new input handlers, e.g. TapHandler instead of MouseArea. The second is to setup a release branch in the CI system so that there is a 5.12 version of the book built separately. I suspect that this will force me to learn more Travis tricks :-)

Merging QmlBook Contents

What better way to spend a lazy Christmas day than to merge some of the new chapters to the QmlBook?

Since having updated the CI system, there is a bit of manual merging forth and back to get each new piece of contents on-line. Specifically, rebase my fork’s master to upstream/master, then rebase my working branch on my master, and then pushing.

One of the newly added chapters cover Qt Quick Controls 2, which is the recommended way to create controls such as buttons, sliders, checkboxes, menues, and so on. Here we look at how you target various form factors such as desktop and mobile, but also how to maintain a common code base between the two.

The other new chapter has a look at Qt for Python from a QML perspective. This chapter goes from the very basic all the way to exposing a Qt model representing the data of an existing Python module to QML.

Kookbook 0.1 – write and manage your kitchen recipes

Release Time

A little while ago, I blogged about an application I was writing for my cooking recipes.

I have now gotten to a point where I will declare it version 0.1. The release can be found on a KDE Download server near you: https://download.kde.org/unstable/kookbook/kookbook-0.1.0.tar.xz.mirrorlist.

Desktop app

As written back then, Kookbook is basically displaying markdown, parses semi-structured markdown for ingredients and tags and allows accessing the recipes that way. Kookbook also offers to open a system editor for editing the content.

This is the “normal” view:

Support for images in recipes has also been added since previous blog post.

Mobile app
Since the may blog post, I have also written a little more basic touch-friendly user interface. It does not offer the full set of desktop features, namely it doesn’t offer to launch an editor for you, and it also only allows to access the recipes thru their names, not thru all the other ways of finding recipes. Though the last part is up to discussion for further releases.

The main page looks like

And lets you search thru the titles to find the one you are after.

The recipe view is more or less the same.

The code

The code itself is mit/x11 licensed, and contains a couple of interesting bits that others might want to take advantage of:

  • Kirigami file dialog. Could be polished and upstreamed.
  • Qt Markdown capability (with libdiscount). Could be librarifyied

Have fun
Go forth, do cooking. And feel free to share recipes. Or create patches.

Tableview performance

by Richard Moe Gustavsen (Qt Blog)

In my previous blog post, I wrote about the new TableView for Qt-5.12. What I didn’t mention was how the new TableView performs compared to the old TableView in QtQuick Controls 1. However, the old version had some serious performance issues, which is what led us to implement a new one from scratch. The reason for the bad performance comes from the fact that it’s written on top of ListView. But ListView is designed and optimized to show only one column, which of course is problematic when you try to use it to show a table with multiple columns.

To work around this limitation, the old TableView implements a little hack: it takes each column delegate and puts them side-by-side to create one fat row delegate. From ListViews point of view, it looks like a normal list delegate. The result is that whenever a new row is flicked in, all the items inside that delegate (which is one item for each column) will be instantiated in one go. Although this is not a disaster for a table with only a handfull of columns, performance takes a major hit when a table is of a non-trivial size. And to be fair, the old TableView was never designed to handle anything else. But for tables where you have, lets say, hundred columns or more, you will create hundred new items for each row flicked in. And most of them ends up hidden outside the viewport. And that is actually the best case; a delegate is normally composed of many items, so the item count will be even higher. The video underneath shows how scrolling can grind to a halt when using a model with only thirty columns.

The new TableView doesn’t suffer from the same problems. It’s written directly in C++ on top of Flickable (not ListView), and optimized to show any number of columns. Most importantly, compared to the old version, it’ll only create and show columns that actually ends up visible on screen. That alone will of course have a dramatic improvement. The same is true when calculating the various sizes of the view, like the table width or the individual column widths: it will only focus on what is loaded and visible, and use that for calculating and predicting the rest. A declarative API for setting e.g all the column widths would for sure be nice for small tables, but just doesn’t scale for models with potentially hundreds, or even thousands of columns. Here we had to make a design decision, where we ended up using a columnWidthProvider to favor speed and flexibility, over a more traditional declarative API like the one used in the old version. The new TableView is basically designed from the ground up to have the same performance and memory usage irrespectively of the size of the model.

Another important improvement is the reusing of delegate items. When applied, it doesn’t really matter if a delegate is a composition of many items, as you don’t end up instantiating them over and over anyway. While the old TableView is actually making an effort to reuse items, it somewhat fails because it’s trying to make this process transparent to the application. As such, when a row is pooled, it unbinds model properties and clear variables, which can lead to a chain reaction of signals being emitted, which again can lead to unnecessary layouts and repaints. The more columns, the more items to reset. Compare this to the new TableView, which is instead completely open about it, and do as little as possible during the same process. It basically leaves it to the developer to decide what needs to be done, if anything, to a reused item. This will lower the cost even more. It also helps, of course, that the reuse implementation for the new version is not a hack on top of ListView, but instead written directly into the model and view classes from C++.

The video underneath shows the new TableView working on a model with 50,000 columns without performance problems.

To sum up, it is not surprising that the performance of the new TableView is on a whole different level than the old version. The old version was written to temporarily fill a hole in the QtQuick Controls 1 desktop offering, and was never intended to be used for models with a high column count. The new version has a higher performance, but it’s also more bare-bone. It aims to have the same usage, flexibility and speed as ListView, but in two dimensions instead of one.

The post Tableview performance appeared first on Qt Blog.

Qt 3D Studio Performance Improvements

Good performance of 3D applications is essential for achieving the desired user experience. While the 3D assets are the most important items affecting the performance, the 3D engine itself needs to be highly efficient in what it does. We have been looking into ways for improving the performance of Qt 3D Studio and especially on how to reduce the CPU load and RAM consumption of 3D applications.

We released Qt 3D Studio 2.2 last week with a lot of cool features, explained in the release blog post. With this blog, the focus is on a couple of items provided by Qt 3D Studio 2.2 that significantly improve the performance and memory consumption. First, we’ll look into leveraging texture compression to reduce RAM consumption and to improve the startup time. Later in the blog post, we’ll dig into the new, still experimental, renderer provided by Qt 3D Studio 2.2. The new renderer, as well as the upcoming new animation system, is specifically developed to reduce the CPU load of Qt 3D Studio applications.

Using Texture Compression for 3D Assets

Qt 3D Studio 2.2 provides support for KTX texture format, enabling the use of various different compression algorithms, such as ETC and ASTC compression. Texture compression helps a lot in reducing memory consumption as well as application startup time. ASTC is a compression technique specified by the Khronos Group and stands for Adaptable Scalable Texture Compression. The ASTC compressed textures are then packaged into a KTX container (another Khronos Group standard, also used by Qt Quick) and used by the Qt 3D Studio. Use of compressed textures is enabled from the Qt 3D Studio Editor (see documentation). Currently, the compressed textures need to be created separately.

The graph below visualizes the impact of compressed textures for the RAM consumption.


The impact depends on the application. In these measurements, we have three different 3D usage scenarios, called Scene 1, Scene 2 and Scene 3. These are benchmark applications created specifically for testing purposes. They run continuously as part of our performance testing system to detect possible regressions (and improvements as well, of course). The impact of texture compression on a real-life Qt 3D Studio application depends upon the application, but the test applications (scenes) give a good impression on how applications of varying complexity can benefit from texture compression.

With ASTC texture compression (we have set it with 4×4 block size and linear rgb format) the memory consumption is reduced by 23MB (20%)  in the simplest Scene 1 test case, by 41 MB (28%) in the Scene 2 and by 56 MB (25%)  in the Scene 3 test (the most complex one of the three). On average, the tests using texture compression yield a 24% reduction in RAM consumption, which is quite a nice saving of that scarce RAM.

The graph below visualizes the impact of compressed textures for the startup time of the application.


The startup time improvement with texture compression is 57% (from 0,23 to 0,1 s) for Scene 1, 64% (from 0,55 to 0,2 s) for Scene 2 and 65% (from 0,85 to 0,3 s) for Scene 3. The time is measured from starting to load the presentation until the first frame is shown. On average, the startup time is reduced by 62%, so it really pays off to use compressed textures.

Note that all these can be directly achieved using the latest Qt 3D Studio 2.2 release and using the supported texture compression for the graphics assets.

Dragon – the New Renderer and Animation System for Qt 3D Studio

The default renderer and animation system of Qt 3D Studio 2.2 are still based on the same version as before. But behind the scenes we are also working on a new renderer and animation system codenamed “Dragon”, bringing performance improvements to the Qt 3D Studio Runtime. These are still experimental with Qt 3D Studio 2.2, but can be enabled to achieve some improvements. The intention is to make the “Dragon” renderer and animation system the default choice with the Qt 3D Studio 2.3 release (scheduled for March 2019).

To see the impact of the new renderer and the animation system on the CPU usage, we tested it on NVIDIA Jetson TX2 (64bit ARM embedded processor) and Intel i7-6700 equipped with NVIDIA Quadro P2000 graphics (i.e. a regular desktop PC), both running Linux as the operating system. Same test scenes as with the texture compression benchmark were used, but with no compression applied (as the texture compression is handled with the GPU, it’s not so relevant for the CPU benchmarking).

This time we compared the default Qt 3D Studio 2.2 with the Qt 3D Studio 2.2 running the new Dragon renderer (experimental with the 2.2 version) and the new animation system coming with Qt 3D Studio 2.3.


The CPU load is reduced on average by 45% with the NVIDIA TX2. The reduction varies a bit between the scenes, but is roughly on the same level (38-49% improvements in the different test cases).


Running the same comparison on an Intel i7 desktop PC, the CPU load reduction is 63% on average (59-67% improvements in the different test cases).

As seen from the results, the new Dragon renderer provides important optimization for the CPU utilization. The new renderer improves the CPU usage especially in scenes where there are many objects, but only a few of them animated between frames. It detects changes in different objects and ensures that interdependent jobs only process necessary intermediate values. The new renderer alone will not improve scenes where all objects are continuously animated, but it can significantly cut down the CPU usage in certain scenes.

The animation system has also been overhauled to minimize the processing performed for animated values. Previously, animations would be offloaded to a backend job, but this turned out to degrade performance due to additional copying and processing in the offloading step. By coupling the animation system more tightly to the renderer, we have managed to bring down the CPU usage in highly animated scenes as well. The tighter coupling has also made the data flow simpler, which makes the code easier to reason about and maintain.

To enable the new Dragon renderer set the Q3DS_DRAGON environment variable to 1 using the new Qt 3D Studio 2.2 release. The animation system is part of Qt 3D Studio 2.3 release, so to try that one out, use the master branch and enable the animation system by setting the environment variable DRAGONWINGS to 1. The animation system feature is already merged and will be part of the Qt 3D Studio 2.3 release in March 2019.

Getting started with Qt 3D Studio 2.2

The easiest way to get Qt 3D Studio 2.2 is through the Qt online installer. The Qt online installer and offline installers can be obtained from the Qt Download page and commercial license holders can find the packages via their Qt Account. Binary packages are available for Windows, Mac and Linux. If you are using Qt for Device Creation 5.12 images the Qt 3D Studio 2.2 Runtime and Viewer are already included in the images. Please also note that Qt 3D Studio runtime uses Qt 3D module for rendering which means that Qt 3D Studio 2.2 requires Qt 5.12 LTS.

The post Qt 3D Studio Performance Improvements appeared first on Qt Blog.

Qt for Python 5.12 Released

As mentioned in the Qt 5.12 release blog we finally reached the point that we can announce the first release of Qt for Python for Qt 5.12. As it has become custom for the project and expected by Python developers, you can install the release via:

pip install PySide2

Additionally, you can get the wheels from Qt’s official download server, or simply get the source code from our Git repository.

Note that Qt for Python is tightly bound to a particular Qt version and does not inherit the LTS (three years of support) flag from Qt 5.12. This means that this release is supported for one year starting on its release day. Our aim for the future is to release Qt for Python at the same time as the Qt version that Qt for Python is based on. Unfortunately, our release process has not reached this point quite yet.

To get started, take a look at the recent webinar ”Develop Your First Qt for Python Application’‘ on how to develop an application from scratch, based on Qt Widgets and different Python modules. You’ll also see some examples on how to continue developing with other Qt for Python components, such as QML and Shiboken.

PySide2 and Shiboken2

The release consists of two modules. The first module, PySide2, provides Python wrappers for most Qt APIs and the second module, Shiboken2, enables users to wrap their own C++ libraries and make them available to the Python world. Internally the PySide2 module depends on Shiboken.

As you might expect, dropping the Technology Preview (TP) label implies a certain compatibility guarantee. This compatibility statement is somewhat different for Qt for Python users compared to C++ guarantees though. It mostly relies on Qt’s source compatibility guarantee as we use a specific syntax to expose Qt’s C++ API. Any Python application written with Qt for Python 5.12 should continue to work with future releases. On the Shiboken side of things, we are still somewhat off target as we continue to carry the TP label.

When looking at the supported platforms, we currently support Python 2.7 and 3.5+ for the three major desktop platforms, with some limitations.

The Future of the Project

Our future roadmap is full of promising ideas and in January we’ll start sorting out the next steps, which will probably include:

  • Simplifying the deployment of PySide2 applications,
  • Provide a smoother interaction with other Python modules,
  • Support other platform like embedded and mobile,
  • and many others.

With this context in mind, we appreciate any input you may have for the next release. You can either post it here, in our IRC channel on Freenode (#qt-pyside) or directly to our issue tracker under https://bugreports.qt.io .


The post Qt for Python 5.12 Released appeared first on Qt Blog.

Welcome to the 2018 Qt Champions!

Qt Champions

Another year has passed, winter has come so it’s time to celebrate the Qt Champions!

So without further ado:

@christian-ehrlicher was granted the *Rookie of The Year* title. Christian did an impressive number of submissions through this year while beginning only at the end of 2017. He wrote quite a lot of fixes for the model view system as well as test and documentation fixes.

@aha_1980 has again earned the *Quality Assurer* title due to his continuous services on the bug report system as well as doing quality reviews. He’s also actively improving Qt Creator and the QtSerialBus module.

This year’s *Ambassador* title goes to Kazuo Asano who’s a very active IRL Qt promoter in Japan. His various activities including study-sessions, seminar and now a book are doing wonder making Qt known in the empire of the rising sun.

Orgad Shaneh is our *Maverick Of The Year*. He’s the one we can thank for the now famous branch change bot on Gerrit. Bot he implemented as a side project to make the life of the sysadmins and developers easier.

This year’s *Fixer* is Alexander Volkov who’s done a lot of work on the X11/xcb backend that has no secret for him.

@VRonin various helper libraries and examples earned him the *Content Creator* title. His knowledge of Qt’s model view system is also well known and appreciated on the forum.

Due to his extensive presence on several fronts (IRC channel, forums, and more), @GrecKo has well earned the *Community Builder* title.

His many and to the point answers on the forum as well as continuous presence on it made @jsulm the second *Community Builder*.

And last but not least, his friendliness, continuous support, numerous examples and tests through these past years have opened him the door to the hall of fame. Congratulations to @mrjj who becomes the second Qt Lifetime Champion!

Let us all congratulate our Champions!

Many thanks for all the work done with and for the community!

The post Welcome to the 2018 Qt Champions! appeared first on Qt Blog.

Looking towards CES 2019: Predictions and where to find Qt


Hello CES 2019!

One of the main events for automotive industry is less than a month away. Based on the early indicators, this year there will be more emphasis on creating a connected and intelligent vehicle than ever before. New connected experiences and multimodal inputs will be introduced by many companies showcasing at the event. In addition, I predict that we will see a wide range of new vehicle types, other than the standard four wheel vehicle, with displays.

This year The Qt Company and Qt based solutions can be found in multiple places in the event. You can meet The Qt Company with our demos in our private suite 2010 at the Westgate Hotel and at the Genivi event on Tuesday evening. In addition, we are very pleased to have been invited to join Luxoft’s booth, #3107 in the North Hall of the Las Vegas Convention Center, for meetings and quick demos. Together with our partners, we will present high performance visual implementations; integrations for virtual assistants; digital cockpits on different hardware and operating system configurations; and of course the tooling used for all of the solutions.

One thing is sure – our partners and customers will again surprise us with concepts built with Qt that the industry, including us, have not heard of or seen before. If you have a Qt based demo please let us know and remember to use “Built with Qt” icons and stickers!

See you in Las Vegas in January.


Want to schedule a meeting with us on site?  Fill out the form here.

The post Looking towards CES 2019: Predictions and where to find Qt appeared first on Qt Blog.

Qt Installer Framework 3.0.6 Released

We are happy to announce the release of Qt IFW 3.0.6. With Qt IFW you can create your own installers for the supported desktop Qt platforms: Linux, Microsoft Windows, and macOS.

3.0.6 is a bug fix release, here are some of the fixes:

  • Fix crash in updater if component does not exist anymore
  • Decrease metadata dowload amount
  • Fix admin query retry in Windows
  • Register virtual component for uninstall

The full list of bug fixes can be found from ChangeLog.

Precompiled binaries for the Installer Framework can be downloaded from Qt Online Installer, sources and binaries can be found also in Qt Download page (open source) or in your Qt Account.

The post Qt Installer Framework 3.0.6 Released appeared first on Qt Blog.

What’s new with the Wayland platform plugin in Qt 5.12?

Wayland is a display server protocol used on modern Linux systems, the Qt Wayland platform plugin lets Qt applications run on Wayland display servers (compositors).

Continuing the trend from the Qt 5.11 release, the Qt 5.12 release contains a substantial amount of improvements.

Window decorations

Old window decorations

Old window decorations

We’ve received quite a few complaints about the looks of our window decorations over the last few years. The message is usually: “They are ugly and don’t look native.”

On Wayland, window decorations are supposed to be drawn by the client by default. Consequently, Qt’s window decorations will probably never look identical to what other toolkits draw. I.e. there is no “native” look with client-side decorations. That is, however, no excuse for them to be ugly.

In 5.12, I’ve updated our default decoration plugin so it looks like something from this decade. It still won’t be “native” looking, but it looks closer much closer to what the other toolkits draw.

New window decorations

New window decorations

The default window background color is now used for the decorations, so it should follow your Qt theme quite nicely.

Window with dark theme

Decorations follow the theme of the window.

Furthermore, we’ve now also added support for support for the Wayland extension, xdg-decoration unstable v1. Compositors implementing this extension can now tell Qt clients that decorations will be drawn server-side instead of client-side. I.e. the decorations for Qt applications and other toolkits can be identical after all. This is also good news for people running tiling compositors. It’s no longer needed to set the environment variable QT_WAYLAND_DISABLE_WINDOWDECORATION on compositors that implement this extension. Toggling window decorations at runtime is now also possible.

server-side window dsecorations

The server-side-decoration QtWayland Compositor example. The bar at the top with the close button is drawn and handled by the compositor.

xdg-shell stable

On Wayland, the shell extension is the part of the protocol that gives meaning to surfaces, i.e. it communicates things like: This surface is a popup-menu, this is a toplevel window, this is its window title and application id, this is how it should be maximized, resized minimized etc.

In other words, a pretty important part of the protocol. The problem is that, while Wayland has been stable for many years, there has been no stable shell extension for the desktop. wl-shell is considered deprecated, and development has continued with the unstable xdg-shell. Unstable protocols have backwards incompatible changes in every release, this means that when a new version is released, it’s essentially a new, although similar, protocol. If we were to simply update our code to the protocol described in the new version, Qt clients would stop working on compositors not supporting the new version.

We’ve solved this by using a plugin architecture for loading a shell integration at runtime depending on what the compositor supports. In other words, each time a new breaking version of xdg-shell is released, we create a new plugin for it. The exciting news this time, is that xdg-shell finally turned stable in December last year, and with it broke backwards compatibility for the last time.

Consequently, Qt 5.12 adds the last and final shell plugin for xdg-shell. This means we can finally deprecate the old unstable xdg-shell plugins and concentrate on making the one stable plugin great.

High DPI cursors

Giant cursor

Support for high DPI cursors has been added. Cursors are now also loaded lazily to significantly reduce the memory footprint on embedded devices that don’t really need them.

Handling maximization and fullscreen on xdg-shell

Implementing fullscreen and maximization properly on xdg-shell required a huge refactor in how resizing works in Qt Wayland. That refactor is now in place, and Qt applications on all supported versions of xdg-shell should now properly switch between fullscreen, maximized and windowed mode.

Forcing a logical DPI of 96

window with tiny fonts

Sometimes compositors report 1px=1mm (a DPI of 25.4) when they don’t have better data available, causing physical DPI to be unreliable.

Quite a few things in Qt depend on the logical DPI, most notably point sized fonts. Previously, we’ve calculated the logical DPI using the physical size and resolution of the screen. This works great in most cases, but sometimes the physical dimensions that compositors provide are wrong, which usually results in tiny unreadable fonts. So in Qt 5.12, we switched to forcing a DPI of 96 by default. The old behaviour can still be restored by setting QT_WAYLAND_FORCE_DPI=physical in the environment.

Fractional scaling

Support for xdg-output unstable v1 was added. It’s a protocol extension for communicating additional information about screens and is needed to implement fractional window scaling on the compositor side. Read the details in David Edmundsons blog post.

The post What’s new with the Wayland platform plugin in Qt 5.12? appeared first on Qt Blog.

How to create QBSPs from Yocto builds

In Qt for Device Creation 5.12.0, we have enabled additional content installation via QBSPs (Qt Board Support Packages). A QBSP combines toolchain, target device images and set of Qt Creator configurations for particular device into a single file that can be easily shared and installed using the Qt online installer or the Maintenance tool. Technically a QBSP is an archived repository created by the Qt Installer Framework, and it’s creation is now fully integrated into the Yocto builds that are used to create the Boot to Qt Software Stack content.

For all the target devices currently supported in the meta-boot2qt layer, you can create a QBSP simply by issuing a bitbake command:

bitbake meta-b2qt-embedded-qbsp

This will first build both the toolchain and the image, and then package those into a QBSP file with the required Qt Creator configurations. The resulting QBSP file is located in tmp/deploy/qbsp/ folder in your Yocto build environment. The QBSP packaging respects the SDKMACHINE variable, so that if you use environment variable SDKMACHINE=i686-mingw32, a Windows toolchain is packaged into the QBSP.

The Yocto integration is implemented in two classes that can be used even if your target device has not been otherwise integrated into the meta-boot2qt layer. By inheriting the classes and setting up the required variables, you can have a QBSP with your own image for your own target device.


The QBSP will need a suitable device image to include in the package and to achieve this you will need to inherit qbsp-image.bbclass in the image recipe you want to use. You can control the content of the package with variable QBSP_IMAGE_CONTENT. By default Boot to Qt images include a .img file and a .conf file used by the Flashing Wizard.

inherit qbsp-image

  ${IMAGE_LINK_NAME}.img \
  ${IMAGE_LINK_NAME}.conf \


qbsp.bbclass is the main class that handles the creation of the QBSP and you can control the various aspects of it through variables. Most important ones are the dependencies to the toolchain and image task using QBSP_SDK_TASK and QBSP_IMAGE_TASK variables.

For the Boot to Qt Software Stack, this is done in the meta-b2qt-embedded-qbsp.bb recipe:

inherit qbsp

VERSION_SHORT = "${@d.getVar('PV').replace('.','')}"
QBSP_NAME = "Boot2Qt ${PV}"
QBSP_MACHINE = "${@d.getVar('MACHINE').replace('-','')}"

QBSP_SDK_TASK = "meta-toolchain-b2qt-embedded-qt5-sdk"
QBSP_IMAGE_TASK = "b2qt-embedded-qt5-image"

Rest of the variables are then used to control how the installer shows the component and where they are installed. You can optionally also, e.g., add an EULA to the package, which the user would need to accept before they can install the components. You can find this and all the other information about the QBSP specific variables in the documentation.

The post How to create QBSPs from Yocto builds appeared first on Qt Blog.

Board Support Package and Commercial Build Enablers for Qt Partners

Qt partners can deliver support for Qt on their hardware boards a lot easier. We have improved and created features for Qt Board Support Package (QBSP) and ability to create Qt commercial builds on Yocto. The enablers will be part of both Qt 5.9 LTS and Qt 5.12 LTS.

As a partner, building and delivering open source versions of Qt under (L)GPL is a relatively simple affair: All the sources are available and the open source licensing allows the distribution of the assets as long as the open source licenses are attained with the packages.

Less so with a commercial license. If there was no out-of-box support as part of Qt for Device Creation partners or their customers have had to swap and add files manually. In addition, integrating developer tooling such as Qt Creator or Qt for Visual Studio had to be done manually with the help of documentation.

Sounds like a lot of hassle?

We agree.

That’s why we’ve been working hard to make it easier for Qt partners to create support for Qt embedded targets and test them as part of their own continuous integration and quality assurance processes.

QBSP for a super-easy developer tooling setup


The QBSP contains all the IDE configurations for deployment, debugging and profiling, as well as the toolchain and embedded target software required for embedded development. In other words, a developer can set up an embedded target on their IDE by simply installing a QBSP package instead of clicking around and manually configuring the environment.

QBSP has been out an about for some time but the feature hardening and documentation have been… <ahem>… fragmented. We spent a fair amount of time this summer to make the feature simple to use for external parties. We have done the initial documentation of QBSP with Yocto-based embedded Linux as a target, but it can just as easily be used with any other target OS.

In addition, we are also using the QBSP feature ourselves in order to deliver to a wider range of Qt for Device Creation embedded targets (but that is another blog post).

Building commercial Qt from Git

We have also enabled an easy way to create commercial Qt builds from Git. This is primarily an enabler intended for operating system and hardware vendors integrating Qt as part of their own continuous integration and testing. In all simplicity, one can now create Qt images with a -commercial switch.

For verification that the Qt build for the hardware was a success and QBSP for the tooling works, we will initially provide partner documentation. The further planned evolution is to provide partners with additional test applications and mechanisms to improve automated testing capability on partner side.

Partner agreement required

The Qt License Agreement 4 explicitly forbids the distribution of commercial Qt or parts of it without a valid license. The rights to distribute Commercial Qt require a partnership agreement between you and The Qt Company. If you are interested in such a partnership agreement, please get in touch with us through https://www.qt.io/contact-us/

The post Board Support Package and Commercial Build Enablers for Qt Partners appeared first on Qt Blog.

From Trunk to Throttle – It’s Software that drives your car

Consumers are demanding great digital experiences in every context of their daily life – from mobile phones through home entertainment and appliances to cars. The automotive industry is quickly moving from a single static display for information sharing to digital cockpits delivering a wide range of services and applications. The pace of change is accelerated not only by external benchmarks such as mobile devices but also industry forerunners, such as Mercedes Benz, Tesla and Audi. All of them have lifted up the expectations for in-car experience. Responding to the increased digital requirements is different than responding to competition with better cup holders*.

The automotive industry must look at the procurement of software differently in the world of digital cockpits. The current processes and practices are optimized for sourcing hardware components globally. Software components are just glued on top of these practices. It has led to situations where software costs are creeping into projects and platforms. In order to build winning digital cockpits automotive OEMs must lift software sourcing to a totally new level. The concept of Software BOM (bill of materials) is at the core of the change. Software BOM should include all the cost related to the product lifecycle – from concepting to deployment and updates. Software decisions also have an indirect impact on hardware cost such as memory (size and quality) and boards (performance and availability), but in this blog series only direct BOM items are covered.


The automotive industry today has well-established practices for managing bill of materials. Actually, a typical car project is a fine oiled procurement process of well-defined specifications, bidding practices over multiple rounds and established supplier layers (called tiers). The fundamental idea behind the process is that a car can be departmentalized into small independent units and each unit’s cost can be minimized, resulting in an optimum total cost structure at the end of the day. This is a very good approach when all components are truly independent from each other and do not share anything in common.

A software component, however, has very little independency as everything is connected and often shared. Furthermore, great software is typically the result of several phases from user experience definition and development to final target optimization. Development in one component may have requirements on other components. Thus, software procurement must be seen as a system purchase and not as a component purchase.

There is a simple way to test whether an OEM is mastering Software BOM or not – by just asking one question at the start of production (SOP) ceremony: „What is the software cost per car for this model?“ A black belt is given when you get an answer consisting of a number and currency. All other answers should lead to a change how software decisions are being made.

Would you like to hear more about what is preventing optimized BOM for automotive OEMS. Stay tuned!

Tero Marjamäki
* www.theatlantic.com / cupholders are everywhere

The post From Trunk to Throttle – It’s Software that drives your car appeared first on Qt Blog.

Qt 3D Studio 2.2 Released

We are happy to announce that Qt 3D Studio 2.2 has been released. Qt 3D Studio is a design tool for creating 3D user interfaces and adding 3D content into Qt based applications.  With Qt 3D Studio you can easily define the 3D content look & feel, animations and user interface states. Please refer to earlier blog posts and documentation for more details on Qt 3D Studio.

New material system

One of the great new features in the Qt 3D Studio 2.2 release is the redesigned Material system. Applying material changes to several objects that share the same material can be now done by simply applying the changes to a single material.

New material system

Materials are now part of the Project View

The way that materials are applied when importing 3D models has been greatly improved. Materials are now part of the Project assets tree view and stored as a separate material definition files as part of the project file structure. This enables also sharing materials between projects. For details please refer to the Materials and Shaders documentation for details how to create and manage materials.

Scene View

Creating pixel perfect UI of course requires attention to detail and a lot of pixel peeping. The 2.2 release introduces a zoomable view for Scene Camera.

Scene Camera View

Scene Camera View

All Qt 3D Studio views are dockable so you can place the Scene view anywhere in the view layout or undock the view to a separate window.

Sub-Presentation Handling

We have done also great improvements to the Sub-Presentation management. Sub-Presentations are now part of the Project View which makes it easier to switch between sub-presentations and add sub-presentation content to the main presentation. Please refer to the documentation for details how to use Sub-Presentations in your project.

Compressed Textures

In Qt 3D Studio 2.1 runtime we introduced the compressed texture support in the runtime and now we have added an option to enable the compressed textures in the Editor Presentation settings. Doing the actual compression requires external tools (such as ETCPACK). In the future versions of Qt 3D Studio, we are introducing more integrated workflow for managing and optimizing the project assets.

Stereoscopic rendering (Technology Preview)

We are also excited to introduce Stereoscopic rendering as a new feature to the Qt 3D Studio runtime. Feature can be tested with the Viewer by enabling the Stereo Mode from the View menu.

Strereoscopic rendering

Enabling stereoscopic mode in the Viewer

Supported stereo modes are: Top-Bottom, Left-Right and Anaglyph rendering. Also eye separation can be increased/decreased from the menu. We will be introducing the QML API for controlling the stereo mode properties in the future releases.

Performance optimization for the runtime

We have been working hard to squeeze our more rendering performance from all kinds of embedded devices and the first set of changes are included in the 2.2 release. We consider these changes to be still experimental and for that reason the new rendering pipeline needs to be explicitly enabled when running the Qt 3D Studio based application. You can test the new rendering by setting Q3DS_DRAGON environment variable to 1. We will be getting more into details on what kind of performance improvements we have been seeing in our tests in a separate blog post. Stay tuned.

View3D QML element

In the QML API we have introduce a new View3D items which can be used to display the contents of a single Qt 3D Studio layer in a Qt Quick scene. This allows placing 3D objects in several places in Qt Quick Scene instead of one rectangular 3D view area. You can also do the Scene composition in the Qt Quick side.

Getting started

Qt 3D Studio 2.2 is available through Qt online installer under the Tools section. We also provide standalone offline installers which contain all you need to start designing Qt 3D Studio User Interfaces. Online installer also contains pre-build runtime for Qt 5.12 which is needed for developing Qt applications using Qt 3D Studio UI. Qt online installer and offline installers can be obtained from Qt Download page and commercial license holders can find the packages from Qt Account. Binary packages are available for Windows and Mac. For the first time we are also providing technology preview binary packages for Linux.

Instructions for building the editor & runtime please refer to the README file. If you are targeting for embedded systems with running e.g. RTOS you need to build the Qt 3D Studio runtime component for the target operating system. Qt 3D Studio runtime can be found from the git repository. If you are Qt for Device Creation Boot2Qt images the Qt 3D Studio Runtime and Viewer are included in the images. Please also note that Qt 3D Studio runtime uses Qt 3D module for rendering which means that Qt 3D Studio 2.2 requires Qt 5.12.

Some example projects can be found under examples folder in the installation directory. Additional examples and demo applications can be found from https://git.qt.io/public-demos/qt3dstudio repository. If you encounter issues with using Qt 3D Studio or you would like to suggest new feature, please use Qt3D Studio project in the https://bugreports.qt.io



The post Qt 3D Studio 2.2 Released appeared first on Qt Blog.

QtCreator CMake for Android plugin

Santa Claus is coming to … wait a minute, it’s not Christmas yet!

I have the pleasure to let you know that KDAB has contributed to Qt with yet another super cool project! It’s about QtCreator CMake for Android! I know it’s a strange coincidence between this article and The Qt Company’s decision to ditch QBS and use CMake for Qt 6, but I swear I started to work on this project *before* they announced it 🙂 ! This plugin enables painless experience when you want to create Android apps using Qt, CMake and QtCreator. It’s almost as easy as Android Qmake QtCreator plugin! The user will build, run & debug Qt on Android Apps as easy as it does with Qmake. Before I go into the boring details, let’s see what the requirements are and, more importantly, when it will be available! Requirements:

  • cmake 3.7 or newer (needed for server support in QtCreator)
  • NDKr18 or newer (only Clang and libc++ shared are supported)
  • Qt 5.12.1 (was too late for this patch to get in 5.12.0)

When will it be available? Well, I started the blog with the Santa on purpose, because, sadly, it’s too late to push it in QtCreator 4.8 and it will be available in the next version (4.9). If you can’t wait for QtCreator 4.9 and you like to try it sooner, you can apply this patch on top of QtCreator’s master branch. Now back to technical details, in order to build your Qt Android application, this plugin must do some magic:

  • after it builds the C++ bits, it copies all the targets (DynamicLibraries) into “{build_folder}/android/libs/{arch}”
  • generates android_deployment_settings.json, which is needed by androiddeployqt tool

After this step, androiddeployqt will complete your Android Qt APK by copying all the Qt dependencies (libs & resources). Last but not least, these are qmake features that you’ll not find in cmake:

  • IDE management for ANDROID_PACKAGE_SOURCE_DIR yes, it supports even the same naming as qmake. You’ll need to add the following piece of cmake script to your CMakeLists.txt file:
        set(ANDROID_PACKAGE_SOURCE_DIR &quot;${CMAKE_CURRENT_SOURCE_DIR}/android&quot; CACHE INTERNAL &quot;&quot;)

    The CACHE is mandatory, otherwise QtCreator won’t see the variable and it won’t use it

  • IDE support ANDROID_EXTRA_LIBS, you’ll need to add the next piece of CMake script to your CMakeLists.txt file
        if (ANDROID_ABI STREQUAL &quot;armeabi-v7a&quot;)
            set(ANDROID_EXTRA_LIBS ${CMAKE_CURRENT_SOURCE_DIR}/3rd-party/android_armeabi-v7a/ssl/libcrypto.so ${CMAKE_CURRENT_SOURCE_DIR}/3rd-party/android_armeabi-v7a/ssl/libssl.so CACHE INTERNAL &quot;&quot;)

    The previous snippet will add libcrypto.so and libssl.so files ONLY for armeabi-v7a android ABI.

Note: KDAB offers training in CMake, including all the latest tips from our trainers, who are all active developers.

The post QtCreator CMake for Android plugin appeared first on KDAB.

Additional Device Creations targets available under Qt Account

We have enabled an improved ability to add new device creation targets to existing Qt releases outside of Qt release schedules. In practice this means, that Qt for Device Creation license holders can find additional embedded target support packages under their Qt Account downloads, additionally to those available under Qt Online Installer and Maintenance tool.

Qt Board Support Package overviewWe have had the ability to upload QBSP (Qt Board Support Package) in to Qt installation through the Maintenance tool for several releases already, but now all the necessary pieces for end to end support are coming together.

QBSP is file format having required toolchains, target hardware firmware, operating system, Qt and Boot to Qt demo application, required configurations for IDE (both Qt Creator and Microsoft Visual Studio) and all other necessary bits and pieces in one package. The QBSP makes adding new target hardware support for embedded developers super easy.

Qt Board Support Package downloads page In future, developers can find additional embedded target support packages, QBSP files for download under their Qt account (account.qt.io). Remember to first select your license (Qt for Device Creation), then product level filter for QBSP downloadables (Qt for Device Creation QBSP) and then the Qt release you are using (Qt 5.12.0 in the above picture).

The big benefit of this model is our ability to open up our delivery channel and QBSP creation for external parties  as well as remove dependency from Qt release schedules and available supported hardware for each release.

The post Additional Device Creations targets available under Qt Account appeared first on Qt Blog.

Cutelyst 2.6.0 released! Now on VCPKG and Buildroot

Cutelyst, a Qt Web Framework has upped to 2.6.0. This release is full of important bug fixes and is the best version when targeting Windows OS so far. It reached 5 years old, 440 stars on GitHub and since the last release has had many users asking questions, reporting issues and making pull requests.

Until now Windows support was a thing I mostly trusted Appveyor compiling and running tests fine, but this changed a bit in this release, I got a freelance job where some terminals would be editing images to be printed on T-Shirts, then they sent their art to a central server which receives and print, so, after I finished the QtQuick application and managed to convince them of running the terminals on KDE/Plasma as it was basically a kiosk full screen application I went on writing the server part.

Using Cutelyst on the server was a perfect match, the process was a Qt Widgets application, that, when linked to Cutelyst::WSGI could start listening all on the same process without issues, every terminal were connected via websockets protocol, which was just awesome, whenever I changed a terminal config I could see it changing instantly on the terminal, QWebSocketServer class could indeed do the same, but, to create the T-Shirt Art Fonts and Pictures needed to be "installed" on the terminal. Now with HTTP capabilities I simply exported all those folders and the whenever I sent a new JSON with config to the terminals, it contained the URLs of all these files which where updated in a blink.

On deploy time it was clear that using Windows on the server was a better option, first I'd need to give support for them on how to configure printers and use the system, also, printer drivers could also cause me troubles, so whatever let's just compile it and get the money.

In order to make things easier I managed to get VCPKG to build a Qt5 for me, in a command line fashion, after that I saw how easy it was to create a package for Cutelyst, it's upstream now, you just need to type:

vcpkg install cutelyst2

This will pull qt5-base package, and get you a working Cutelyst that easy, sadly Qt5 packages didn't work on Linux nor on MacOS (both with issues filled).

Thanks to this project, several Windows related issues have been fixed, still work to do but I have an app on production on Windows now :)

I'm still no Windows fan, so I ended up configuring MXE and cross compiling Cutelyst and my application for Windows on Linux with it.

If you are doing embedded stuff, Cutelyst is also available on buildroot.

Besides that Cutelyst 2.6.0 has some other very important bug fixes.

Get it here!