Qt 5

We are happy to announce the release of Qt Creator 4.9 Beta2! Please have a look at the blog post for the Beta for an overview of what is new in Qt Creator 4.9. Also see the change log for a more complete list of changes. Get Qt Creator 4.9 Beta2 The ... [More] opensource version is available on the Qt download page under “Pre-releases”, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.9 Beta2 is also available under Preview > Qt Creator 4.9.0-beta2 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.9 Beta2 released appeared first on Qt Blog. [Less]

There has been lots of excitement around WebAssembly and more specifically Qt for WebAssembly recently. Unfortunately, there are no snapshots available yet. Even if there are, you need to install a couple of requirements locally to set up your ... [More] development environment. I wanted to try it out and the purpose of this post is to create a developer environment to test a project against the current state of this port. This is where docker comes in. Historically, docker has been used to create web apps in the cloud, allowing to scale easily, provide implicit sand-boxing and being lightweight. Well, at least more lightweight than a whole virtual machine. These days, usage covers way more cases Build Environment (standalone) Development Environment (to create SDKs for other users) Continuous Integration (run tests inside a container) Embedded runtime Containers and Embedded are not part of this post, but the highlights of this approach are Usage for application development Resources can be controlled Again, sandboxing / security related items Cloud features like App Deployment management, OTA, etc… We will probably get more into this in some later post. In the meantime, you can also check what our partners at Toradex are up to with their Torizon project. Also, Burkard wrote an interesting article about using docker in conjunction with Open Embedded. Let’s get back to Qt WebAssembly and how to tackle the goal. The assumption is, that we have a working project for another platform written with Qt. The target is to create a container capable of compiling above project against Qt for WebAssembly. Next, we want to test the application in the browser. 1. Creating a dev environment Morten has written a superb introduction on how to compile Qt for WebAssembly. Long-term we will create binaries for you to use and download via the Qt Installer. But for now, we aim to have something minimal, where we do not need to take care of setting up dependencies. Another advantage of using docker hub is that the resulting image can be shared with anyone. The first part of the Dockerfile looks like this: FROM trzeci/emscripten AS qtbuilder RUN mkdir -p /development WORKDIR /development RUN git clone --branch=5.13 git://code.qt.io/qt/qt5.git WORKDIR /development/qt5 RUN ./init-repository RUN mkdir -p /development/qt5_build WORKDIR /development/qt5_build RUN /development/qt5/configure -xplatform wasm-emscripten -nomake examples -nomake tests -opensource --confirm-license RUN make -j `grep -c '^processor' /proc/cpuinfo` RUN make install Browsing through the Docker Hub shows a lot of potential starting points. In this case, I’ve selected a base image which has emscripten installed and can directly be used in the follow up steps. The next steps are generally a one-to-one copy of the build instructions. For now, we have one huge container with all build artifacts (object files, generated mocs, …), which is too big to be shared and those artifacts are unnecessary to move on. Some people tend to use volume sharing for this. The build happens on a mount from the host system to the image and install copies them into the image. Personally, I prefer to not clobber my host system for this part. In the later versions of Docker, one can create multi-stage builds, which allow to create a new image and copy content from a previous one into it. To achieve this, the remaining Dockerfile looks like this: FROM trzeci/emscripten AS userbuild COPY --from=qtbuilder /usr/local/Qt-5.13.0/ /usr/local/Qt-5.13.0/ ENV PATH="/usr/local/Qt-5.13.0/bin:${PATH}" WORKDIR /project/build CMD qmake /project/source && make Again, we use the same base container to have em++ and friends available and copy the installation content of the Qt build to the new image. Next, we add it to the PATH and change the working directory. The location will be important later. CMD specifies the execution command when the container is launched non-interactively.   2. Using the dev environment / Compile your app   The image to use for testing an application is now created. To test the build of a project, create a build directory, and invoke docker like the following   docker run --rm -v This will launch the container, call qmake and make and leave the build artifacts in your build directory. Inside the container /project/build reflects as the build directory, which is the reason for setting the working directory above. To reduce typing this each time, I created a minimal batch script for myself (yes, I am a Windows person ). You can find it here.   3. Test the app / Containers again Hopefully, you have been able to compile your project, potentially needing some adjustments, and now it is time to verify correct behavior on runtime in the browser. What we need is a browser run-time to serve the content created. Well, again docker can be of help here. With no specific preference, mostly just checking the first hit on the hub, you can invoke a runtime by calling   docker run --rm -p 8090:8080 -v This will create a webserver, which you can browse to from your local browser. Here’s a screenshot of the animated tiles example   Also, are you aware that there is also Qt Http Server being introduced recently? It might be an interesting idea to encapsulate it into a container and check whether additional files can be removed to minimize the image size. For more information, check our posts here. If you want to try out the image itself you can find and pull it from here.   I’d like to close this blog asking for some feedback from you readers and get into some discussion. Are you using containers in conjunction with Qt already? What are your use-cases? Did you try out Qt in conjunctions with containers already? What’s your experience? Would you expect Qt to provide “something” out-of-the-box? What would that be?   The post Using Docker to test Qt for WebAssembly appeared first on Qt Blog. [Less]

Fur a long time I wanted to create a full Continuous Integration environment that uses Qt for both building apps and testing. In fact, one of the most important things for me was to find the right way to integrate Qt Test. For CI I've started to use ... [More] Travis since it is one of the most widely used environments in GitHub. I took that decision after seeing other Qt projects (Musescore and Stellarium) using it. La entrada Integrating Qt Test in Travis CI aparece primero en My C++ & Qt blog - Cesc M.. [Less]

“Honestly Qt’s documentation is pretty close to perfect, I wish other framework’s documentation were as good. Keep doing what you’re doing.” “Documentation has always been top-notch” “The documentation is great.” These quotes are from you, the ... [More] users of Qt. For someone like me, who works with documentation for a living, this is awesome. It’s extremely cool to work with docs that receive this kind of feedback from its users. In light of the sheer size of the project, it becomes even more impressive. The online documentation for Qt 5.12 spans over 18000 pages. It covers more than 3000 classes and QML types across more than 120 modules. It’s simply massive. So it probably doesn’t come as a surprise that we also get some suggestions regarding how we can improve the docs. Easier navigation, more code snippets, more examples, missing documentation (Qt3D, anyone..?) – these are all regulars. My personal favorite is perhaps not the nicest way of putting it, but it certainly does get the point across [0]. Okay, so what’s this all about, then, that makes me write a blog post about it? The future of documentation: a workshop Monday 11th and Tuesday 12th March, some of us that take pride in Qt’s documentation come together for a two-day workshop about documentation. The workshop takes place at The Qt Company’s offices in Oslo. We’re joined by colleagues from Finland and Germany. We’re lucky enough to have a technical writer from Luxoft join us as well, to help us understand more about what it’s like to work on Qt documentation from the outside. From developers and tech writers to product managers, we’re putting our heads together to figure out how we can improve our docs further. We want you to have more fun and get more things done. The agenda is already on the wiki [1], along with some ideas about what we want to address. If you want to join us in this workshop, I’d be happy to welcome you aboard – get in touch with me so we can sort out the practicalities. But it doesn’t matter if you can’t join – I still want to hear from you out there. What can we do to improve the docs? Have you seen something done brilliantly in some other documentation set? (Yes, they’re brilliant, but don’t expect Qt docs to mimic IKEA assembly instructions anytime soon) Perhaps you want to contribute to the docs, help out with some of the examples? Whatever it is, make use of the comment section to let us know about it. If you’re not a fan of the comment section, feel free to send me an email or look me up on IRC [0] – “Your documentation examples are sometimes shitty in the sense that they cover only trivial cases, but not advanced ones.” [1] – https://wiki.qt.io/Documentation_Workshop_2019 The post The future of documentation appeared first on Qt Blog. [Less]

“Honestly Qt’s documentation is pretty close to perfect, I wish other framework’s documentation were as good. Keep doing what you’re doing.” “Documentation has always been top-notch” “The documentation is great.” These quotes are from you, the ... [More] users of Qt. For someone like me, who works with documentation for a living, this is awesome. It’s extremely cool to work with docs that receive this kind of feedback from its users. In light of the sheer size of the project, it becomes even more impressive. The online documentation for Qt 5.12 spans over 18000 pages. It covers more than 3000 classes and QML types across more than 120 modules. It’s simply massive. So it probably doesn’t come as a surprise that we also get some suggestions regarding how we can improve the docs. Easier navigation, more code snippets, more examples, missing documentation (Qt3D, anyone..?) – these are all regulars. My personal favorite is perhaps not the nicest way of putting it, but it certainly does get the point across [0]. Okay, so what’s this all about, then, that makes me write a blog post about it? The future of documentation: a workshop Monday 11th and Tuesday 12th March, some of us that take pride in Qt’s documentation come together for a two-day workshop about documentation. The workshop takes place at The Qt Company’s offices in Oslo. We’re joined by colleagues from Finland and Germany. We’re lucky enough to have a technical writer from Luxoft join us as well, to help us understand more about what it’s like to work on Qt documentation from the outside. From developers and tech writers to product managers, we’re putting our heads together to figure out how we can improve our docs further. We want you to have more fun and get more things done. The agenda is already on the wiki [1], along with some ideas about what we want to address. If you want to join us in this workshop, I’d be happy to welcome you aboard – get in touch with me so we can sort out the practicalities. But it doesn’t matter if you can’t join – I still want to hear from you out there. What can we do to improve the docs? Have you seen something done brilliantly in some other documentation set? (Yes, they’re brilliant, but don’t expect Qt docs to mimic IKEA assembly instructions anytime soon.) Perhaps you want to contribute to the docs, help out with some of the examples? Whatever it is, make use of the comment section to let us know about it. If you’re not a fan of the comment section, feel free to send me an email or look me up on IRC [0] – “Your documentation examples are sometimes shitty in the sense that they cover only trivial cases, but not advanced ones.” [1] – https://wiki.qt.io/Documentation_Workshop_2019 The post The future of documentation appeared first on Qt Blog. [Less]

We are happy to announce the release of Qt Creator 4.8.2! I failed to decide which individual bug fixes to highlight here, so please just have a look at our change log for details :). Get Qt Creator 4.8.2 The opensource version is available on the Qt ... [More] download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.8.2 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.2 released appeared first on Qt Blog. [Less]

I am happy to announce we have release Qt Automotive Suite 5.12.1 today. This is first patch release for Qt Automotive Suite 5.12 LTS and it is based on Qt 5.12.1 release. As a patch release it doesn’t bring any new features but many bug fixes at the ... [More] top of previous Qt Automotive Suite 5.12.0 release. We will continue releasing regular updates as new patch level release in the future; next update should be available few weeks after soon coming Qt 5.12.2 release. You can get Qt Automotive Suite 5.12.1 as an update to existing Qt Automotive Suite 5.12.0 installation via maintenance tool. Or you can do clean installation by using Qt Online Installer which can be found from your Qt Account. Please install Qt Automotive Suite 5.12.1 now & give us feedback via Jira. The post Qt Automotive Suite 5.12.1 released appeared first on Qt Blog. [Less]

Previously I have been writing about how topics in messages can have a significant impact on the amount of data for publishing via MQTT. Since then the MQTT version 5 standard has been released and first implementations are available. Naturally, Qt ... [More] MQTT follows along and this post will reflect how new features in the standard are available in our Qt for Automation module. In this post, we will not go into every detail of the updated specification, but rather showcase some highlights and benefits for upgrading to the latest versions. Also, before we forget, make sure to sign up for my upcoming webinar on the same topic. Tune in and discuss! Topic Alias As a reminder, the topic of a message is always sent uncompressed in clear text as part of the byte stream. For example, a sensor network reporting temperature values could have a topic hierarchy designed as sensors/Europe/2af89b42-d2a6-11e8-a8d5-f2801f1b9fd1/Temperature Consequently, the byte layout of a message has this shape: This sums up to 71 bytes for each message, with 4 bytes containing the requested information. In the previous post, we talked about methods like Reducing the topic length Combining multiple sensor values to enhance the overhead-information ratio. MQTT5 introduces Topic Aliases which allow assigning IDs to a specific topic. During the connection handshake, the client and the server agree on whether topic aliases are available and what the maximum number of topic aliases is. While ids are available, they can be assigned to topics. This assignment is done during a publish message. The new layout to send a message and concurrently set a topic alias looks like this: For the first message, the data size is 74 bytes, three more than for a conventional publish. However, the second publication already benefits from this concept The message size has been reduced to 11 bytes, simply by exchanging the topic with an ID and keeping the topic string empty. Starting from the second message this is a major improvement to reduce the required bandwidth. It is important to note that topic alias assignments are only set for one connection. Other subscribers on this topic, especially ones that do not use topic aliases, will receive messages including the full topic. Alternatively, those connections can create their own topic alias matching. It is the responsibility of the server to forward topics with either the full topic, or a different alias. Furthermore, topic aliases are not static. An alias can always be re-assigned to another topic.   Let’s move on by showcasing how to use this feature with Qt MQTT. Support for MQTT v5 has been added for Qt MQTT with Qt for Automation 5.12. Connect with topic aliases To set topic alias support for a connecting client, the QMqttClient needs to be updated before connecting to the server const int userMaxTopicAlias = 9; QMqttConnectionProperties userProperties; userProperties.setMaximumTopicAlias(userMaxTopicAlias); client.setConnectionProperties(userProperties); […] client.connectToHost(); Verify that the server supports aliases When a server connected, query that the server also supports topic aliases const auto serverProperties = client.serverConnectionProperties(); const quint16 serverMaxAlias = serverProperties.maximumTopicAlias(); // Returns the number of available aliases A connection can use up to the minimum of client and server topic aliases.   Publish a message while setting topic alias const QMqttTopicName topic(QLatin1String("sensors/Europe/2af89b42-d2a6-11e8-a8d5-f2801f1b9fd1/Temperature")); QMqttPublishProperties aliasProperties; aliasProperties.setTopicAlias(2); client.publish(topic, aliasProperties, msgContent, 1); Internally, Qt MQTT stores the assignment to simplify follow up publications.   Publish follow up messages client.publish(topic, msgContent, 1); There is no need to add the properties for subsequent calls unless the purpose is to reassign an ID. Qt MQTT tries to use topic aliases automatically unless a user specifies them. After a connection has been established and Qt MQTT recognizes support for using topic alias, it “converts” classic publish messages to use topic aliases until all available aliases have been assigned. It uses an internal cache for this purpose, which can be controlled by using above QMqttPublishProperties. There is no heuristics included in that cache, thus we still recommend using topic aliases manually. It depends on the project to identify which topics are frequently used and which topics can create the biggest benefit by using aliases. As a closing note, Qt MQTT also takes care of the subscribing end about topic aliases. The process is the same, with the server specifying the topic and alias match. Qt MQTT then tracks this relationship and passes the full topic string inside a QMqttMessage to not require user specific code for this. If a user wants to know, whether a topic has an assigned alias, the publish properties of a QMqttMessage contain this information. Properties everywhere You might have recognized the usage of a publish property class above. This reveals a new concept introduced with MQTT 5. While staying a lean and simple to use protocol, efforts have been made to allow for more dynamic setups. Properties can be embedded into the existing commands, but it is not a must to include them. Default values cover the most used scenarios or ensure a compatible behavior with MQTT 3.1.1. Providing a zero byte indicates no properties to be set. All available properties and their matching commands are listed below: For each command, a new property class has been introduced with version 5.12. Please check the documentation on how to precisely use them. Security Authentication has been updated in a major fashion within MQTT 5.0, to the extent that a new command AUTH has been introduced. After sending a connection request from a client to a server, the server might ask for further authentication information. This happens via sending an AUTH command including a Continue reason code. The client then needs to provide authentication data, which either leads to successful connection, the server asking for even more data or the connection being closed due to a failed authentication. There is no limit on the number of authentication steps. The actual method used for authentication is decided on the server side. This can be for instance OAuth, or any other functionality integrated on the server side. In Qt MQTT the QMqttClient has an authenticationRequested and authenticationFinished signal to reflect a notification from the server. Furthermore, the authenticate function has been introduced to send authentication data to a server. What’s more? Descriptive arguments can be used to provide more details on the content of messages. And even more, it is now possible to allow servers to provide error messages to a client. This can be of big help when implementing a communication protocol between a client and a server. The standard used to demand a disconnect in case of invalid behavior. It still does, but now a server can include either error codes or even error strings as guidance for the client or the developer. Naturally, all these things are reflected in Qt MQTT. We would like to understand more about your usage of this module and which features would be required most to make your project succeed faster. If you have any comments, feel free to get in touch with us either via the comment section, directly via email or catch me live during the upcoming webinar. The post MQTT version 5 updates and how they apply to Qt MQTT appeared first on Qt Blog. [Less]

That is a great guide where you can find a lot of information and how to implement Drag&Drop in your widgets. La entrada Drag and Drop in custom widgets with Qt aparece primero en My C++ & Qt blog - Cesc M..

It has been a great start into 2019! We recently released Qt 5.12 which comes with multiple performance improvements and thousands of bug fixes– it’s a great release to base your work upon. But we have more in the works: Python language bindings ... [More] , tools for developers and designers, industry-specific offering, and a lot more. Indeed, 2019 looks to be another great year for Qt users! It’s around this time of the year I sit down to write a blog post about our plans and roadmap for the coming year. Typically, some of the items have already been cooking for a while, but some are still plans in the making. If you want to look into the previous roadmap blog posts, here are the ones I wrote for 2016, 2017 and 2018. There is always more to tell than what would reasonably fit in a blog post, but I’ll try to talk about the most interesting items. Before diving any further into the new items planned for 2019, I would like to thank each and every Qt developer for their contribution. We have a great ecosystem with many contributors who have provided multiple extremely valuable contributions throughout the years and continue to shape Qt in the future, too. In addition to those contributing code, we also have many active people in the Qt Project forums, on mailing lists, as well as reviewing code and testing the Qt development releases. The Baseline: Qt 5.12 LTS A lot of our efforts in 2019 will go into further improving Qt 5.12 LTS via multiple patch releases providing error corrections and performance improvements. Qt 5.12 LTS is the third long-term supported Qt 5 release and as such already a great baseline for developing applications. In Qt 5.12.0 we have fixed over 5000 bugs since Qt 5.6.3 and over 2000 since Qt 5.9.7. As all fixes currently go to Qt 5.12 LTS we take further steps ahead of the earlier LTS releases with each Qt 5.12 LTS patch release. In addition to fixing bugs and developing new features, we have put a lot of effort into improving performance and resource consumption of Qt applications – especially those using Qt Quick and Qt 3D Studio. Qt 5.12 LTS added several new features too, and contains all the cool features of earlier Qt 5.11 and Qt 5.10 releases since the previous LTS release of Qt. With Qt 5.6 LTS support ending in March 2019 and Qt 5.9 LTS being in the Strict mode (receiving only the most important fixes) we advise migrating to Qt 5.12 LTS. Not only will your Qt application run faster and better thanks to the bug fixes and performance improvements, but you can also profit from the many new features and optimizations Qt 5.12 LTS comes with. So, the baseline is solid, but 2019 is not going to be merely about bug fixes and polish – we have also many cool new things cooking. Read on for a brief overview of what you can expect to be released during 2019. Python, WebAssembly and other new goodies Qt now fully supports Python with Qt 5.12 LTS. A lot of work has been done to get to this point, and we are really pleased to put all of Qt’s functionality at the fingertips of the growing community of Python developers. The work continues throughout 2019 with improvements and new features. In addition to constantly improving the Python bindings and supporting all the new Qt versions and patch releases, we have some great new features planned for 2019. One highly requested new feature is integration with commonly used Python 3rdparty modules like numpy, pytorch, pandas and matplotlib. Out of these, we expect to provide at least integration to numpy during 2019, possibly some others as well. Easier deployment of Qt for Python applications is another commonly requested item and we aim to provide a better solution in 2019. Other major items include improved integration of QML as well as tooling improvements, especially making Qt Creator an awesome IDE also for Python developers. Another really cool new item is Qt for WebAssembly. It has so far been a technology preview but will become a fully supported platform with Qt 5.13. It has gained a lot more functionality, as well as performance and stability improvements since the first preview release. We continue to improve functionality and fix bugs as more users adopt Qt for WebAssembly and report issues. 2019 will bring a lot of important features and quality-of-life improvements to Qt for WebAssembly users. Windows will be supported as a development host, in addition to Mac and Linux which were already available. We also start providing binary packages of Qt for WebAssembly, just like we do for most of the other supported platforms. New features coming in 2019 include access to local file systems (with the restrictions imposed by the browser sandbox), threading support on browsers where this is enabled, support for system clipboard, and addressing multiple canvases in the browser document. We are also working to enable debugging and to improve linking times for applications to accelerate development. With Qt 5.13 we are adding a technology preview of Qt Lottie, a player for Bodymovin animations. Bodymovin is a plugin to Adobe After Effects tool and there are multiple different player implementations on different platforms – and now a cross-platform one created with Qt. The new player allows easy inclusion and use of these animations in a Qt Quick application. Qt Lottie makes it possible to control the pre-created animation (reverse/start/pause/stop/autoplay etc) and even change the animation source dynamically. From the beginning, we have focused on performance aspects to enable Qt Lottie to be used on embedded devices in addition to the typical targets of these animations like web, desktop and mobile platforms. While the functionality of Qt Widgets is already very comprehensive, we are also planning to add new widgets during 2019. Our current thinking is that a circular progress bar and a switch widget would be good additions. One of them or both should arrive at a computer near you with the Qt 5.14 release. Other than that, we are continuously working to improve Qt Widgets further by fixing bugs and making small improvements where needed. Tools for Developers: Qt Creator and new Qt Lite Tooling In the past releases of Qt Creator, we have done a lot of work behind the scenes to switch to the clang code model. Now that this is done, we have already enjoyed some benefits such as clang-tidy and clazy. During 2019 we plan on bringing better diagnostics management as well as improved performance to the Qt Creator IDE. One development item is to use a symbol database (indexdb) to have a fast, binary representation of the project. This is expected to improve performance a lot compared to parsing the files continuously. We are also improving the Language Server Protocol support and leveraging it to support more programming languages with Qt Creator. The new framework items need good tools and thus we are continuously improving the Python support of Qt Creator to allow great developer experience. Currently just a research item, we might enable the ability to extend Qt Creator via Python in the future. We will update you on where this will lead us towards the latter part of 2019. We are also working to provide out-of-the-box support of Qt for WebAssembly. CMake has been supported by Qt Creator for quite a while. During 2019, we aim to improve the support further and make it easier to start new projects with CMake. We plan to create a CMake based build system for Qt Creator and to better support embedded development with CMake using Qt Creator. Qt Quick Designer, which is part of Qt Creator, will receive new functionality initially developed for Qt Design Studio. While Qt Design Studio is indented for designers, not directly as a development tool, it does share a lot of parts with the Qt Creator IDE. Thus, we can bring many of the usability and ergonomics improvements into Qt Creator’s Qt Quick Designer view. One major new feature coming soon to Qt Creator is the capability to create Qt Quick animations using the new timeline editor in Qt Quick Designer. Qt for Device Creation users will get a major improvement to the Qt Lite configuration tool during 2019. With the new version we are improving the usability of the tool and further extending the configurability of Qt. In addition, we are creating some pre-defined configurations to start from, expected to make it easier to benefit from the tool. One major usability improvement coming with the new version of the Qt Lite configuration tool is capability to directly make the whole configuration with the visual tool, without running separate configure steps. Tools for Designers: Qt Design Studio and Qt 3D Studio One of the biggest investments of 2019 will go into the design tooling for both 2D and 3D user interfaces, as well as into further improving the Qt 3D Studio runtime. The long-term goal is to unify the 2D and 3D design tools into one application, of course still having specialized capabilities for 2D and 3D UI. The first steps towards unification are becoming visible during 2019 with multiple shared components, improved interoperability and unified installation of the tools. Let’s first look into Qt Design Studio, the tool for developing Qt Quick UIs. We published the first release in October 2018. The recently released Qt Design Studio 1.1 provides a lot of polish to the rough edges of the first release, adds merge support for the Photoshop import functionality, as well as brings multiple improvements to the examples and documentation. Also Linux packages are now available in addition to Mac and Windows. During 2019 we will add many important features to Qt Design Studio, for example support for additional graphics design tools such as Sketch, a new easing curve editor and a new property inspector, both shared with Qt 3D Studio as well. We are also improving multi-monitor support, providing project workspace with dockable windows and finetuning the ergonomics and usability of the application. We aim to make also an open-source release of Qt Design Studio, which is currently only available for commercial license holders. Qt 3D Studio is getting a major boost in runtime performance with the 2.3 version in March and 2.4 in June 2019. The renewed renderer and animation system as well as support for asset conditioning provide improved performance, significantly reduced CPU load, greatly reduced loading times of the 3D content, as well as lower memory consumption. Throughout 2019, we are making further improvements, allowing complex real-time 3D applications to run well even on mid-tier hardware. For the low-end 3D hardware we recommend leveraging Qt Quick as much as possible and using real-time 3D only for the parts that really need it. Some of the most interesting new features of Qt 3D Studio coming in 2019 include support for stereoscopic rendering, completely renewed text rendering, distance fields for text, custom vertex shaders and support for precompiled shaders. Qt 3D Studio will also benefit from the new easing curve editor and property inspector, shared with Qt Design Studio. Stereoscopic rendering allows addressing AR/VR use cases easier than before with support for the most common stereoscopic rendering modes. Text rendering of Qt 3D Studio will receive a complete overhaul to be on par with the excellent capabilities Qt Quick offers for text. With Qt 3D Studio we are also looking into providing an improved integration with content creation tools, such as Autodesk Maya. In addition to tool specific integrations, we aim to improve the already impressive list of supported input formats with new ones such as glTF 2.0 and possibly other new formats during 2019. Automation, Automotive and other industries During 2019 we are further developing our offering for safety critical systems. The functional safety certified Qt Safe Renderer will gain the capability to render dynamic text as well as support for large bitmaps. These will allow an even easier creation of complete safety-critical UIs using the Qt Safe Renderer. Furthermore, we are looking into supporting a wider array of hardware as well as possibly running on the simpler real-time operating systems typically available for microcontrollers. Our offering for Automation and Automotive industries will get some important new features as well. For Automation, we are adding support for the CoAP protocol, first as a technology preview and later as fully supported. In addition, Qt OPCUA becomes fully supported with Qt 5.13 (with some of the new APIs such as QML API still TP) and other automation protocols get a few new features. We also plan to look into Qt OPCUA server implementation, allowing seamless Qt experience also when there is a need to create edge gateway applications. Qt Automotive Suite will improve its capabilities of working with digital assistants as well as inter-application operation via a new intent API. We also continue to address multi-domain use cases by further improving Qt Remote Objects (fully supported with Qt 5.12 LTS) and by improving the graphics sharing functionality. Work on addressing constantly lower performance (and cheaper price point) hardware continues throughout 2019. Qt is already running on multiple different Cortex-M4 and Cortex-M7 based microcontrollers and widely supported on various low-end ARMv7 and ARMv8 hardware boards. During 2019, we aim to address additional microcontrollers as well as different low-end real-time operating systems for microcontrollers. We are also thinking how to achieve a great developer experience with Qt for microcontrollers. Our long-term goal is to allow development with Qt for microcontrollers to be as easy as any other platform. Many of the same optimizations and configurability that enables to address the microcontrollers can also be leveraged with the low-end application processors. Qt offers features and functionality not commonly available in the simple frameworks typically used in the low-end devices. With the versatile configuration system, it is possible to choose the needed functionality and leave out the functionality which the application does not require. This allows Qt to fit into a much smaller memory footprint and utilize less system resources than before. Get Involved If you want to learn more about upcoming things for Qt, please stay tuned for new blog posts and webinars about the upcoming features, contact our sales teams or join the discussion in the Qt mailing lists and developer forums. We are always delighted to see new contributors in the Qt Project as well as feedback to the pre-releases of Qt via bugreports. The post Qt Roadmap for 2019 appeared first on Qt Blog. [Less]