Qt 5

Qt for WebAssembly is an exciting new platform for Qt. It means that Qt applications can run in a web browser. This means that deploying a Qt application is as easy as copying the files to your properly configured web server and handing out the url ... [More] , for your users to run in their web browser. Mqtt is a machine to machine communication protocol, which is used for messaging in IoT. Websocket is a two way communication protocol between a web browser and a web server. QtMqtt has been ported to run on the WebAssembly platform, using QtWebSockets as it's transport. There is a catch to getting it working, however. That catch is that you need to use the WebSocketIODevice class that is in the QtMqtt websocketsubscription example app. WebSocketIODevice depends on the QtWebSocket module. You need to copy websocketiodevice.h and websocketiodevice.cpp into your project, using the WebSocketIODevice as QMqttClient's transport. In a nutshell, at a minimum,  code such as this: QMqttClient m_client WebSocketIODevice m_device; m_device.setUrl(m_url); connect(&m_device, &WebSocketIODevice::socketConnected, this, [this]() {     m_client.setTransport(&m_device, QMqttClient::IODevice); } Then you can use the QMqttClient as normal. You can read more about Qt for WebAssembly, QtMqtt and QtWebSockets in the book Hands-On Mobile and Embedded Development with Qt 5 [Less]

As Lars mentioned in his Technical Vision for Qt 6 blog post, we have been researching how we could have a deeper integration between 3D and Qt Quick. As a result we have created a new project, called Qt Quick 3D, which provides a high-level API for ... [More] creating 3D content for user interfaces from Qt Quick. Rather than using an external engine which can lead to animation synchronization issues and several layers of abstraction, we are providing extensions to the Qt Quick Scenegraph for 3D content, and a renderer for those extended scene graph nodes. Does that mean we wrote yet another 3D Solution for Qt?  Not exactly, because the core spatial renderer is derived from the Qt 3D Studio renderer. This renderer was ported to use Qt for its platform abstraction and refactored to meet Qt project coding style. “San Miguel” test scene running in Qt Quick 3D What are our Goals?  Why another 3D Solution? Unified Graphics Story The single most important goal is that we want to unify our graphics story. Currently we are offering two comprehensive solutions for creating fluid user interfaces, each having its own corresponding tooling.  One of these solutions is Qt Quick, for 2D, the other is Qt 3D Studio, for 3D.  If you limit yourself to using either one or the other, things usually work out quite fine.  However, what we found is that users typically ended up needing to mix and match the two, which leads to many pitfalls both in run-time performance and in developer/designer experience. Therefore, and for simplicity’s sake, we aim have one runtime (Qt Quick), one common scene graph (Qt Quick Scenegraph), and one design tool (Qt Design Studio).  This should present no compromises in features, performance or the developer/designer experience. This way we do not need to further split our development focus between more products, and we can deliver more features and fixes faster. Intuitive and Easy to Use API The next goal is for Qt Quick 3D is to provide an API for defining 3D content, an API that is approachable and usable by developers without the need to understand the finer details of the modern graphics pipeline.  After all, the majority of users do not need to create specialized 3D graphics renderers for each of their applications, but rather just want to show some 3D content, often alongside 2D.  So we have been developing Qt Quick 3D with this perspective in mind. That being said, we will be exposing more and more of the rendering API over time which will make more advanced use cases, needed by power-users, possible. At the time of writing of this post we are only providing a QML API, but the goal in the future is to provide a public C++ API as well. Unified Tooling for Qt Quick Qt Quick 3D is intended to be the successor to Qt 3D Studio.  For the time being Qt 3D Studio will still continue to be developed, but long-term will be replaced by Qt Quick and Qt Design Studio. Here we intend to take the best parts of Qt 3D Studio and roll them into Qt Quick and Qt Design Studio.  So rather than needing a separate tool for Qt Quick or 3D, it will be possible to just do both from within Qt Design Studio.  We are working on the details of this now and hope to have a preview of this available soon. For existing users of Qt 3D Studio, we have been working on a porting tool to convert projects to Qt Quick 3D. More on that later. First Class Asset Conditioning Pipeline When dealing with 3D scenes, asset conditioning becomes more important because now there are more types of assets being used, and they tend to be much bigger overall.  So as part of the Qt Quick 3D development effort we have been looking at how we can make it as easy as possible to import your content and bake it into efficient runtime formats for Qt Quick. For example, at design time you will want to specify the assets you are using based on what your asset creation tools generate (like FBX files from Maya for 3D models, or PSD files from Photoshop for textures), but at runtime you would not want the engine to use those formats.  Instead, you will want to convert the assets into some efficient runtime format, and have them updated each time the source assets change.  We want this to be an automated process as much as possible, and so want to build this into the build system and tooling of Qt. Cross-platform Performance and Compatibility Another of our goals is to support multiple native graphics APIs, using the new Rendering Hardware Interface being added to Qt. Currently, Qt Quick 3D only supports rendering using OpenGL, like many other components in Qt. However, in Qt 6 we will be using the QtRHI as our graphics abstraction and there we will be able to support rendering via Vulkan, Metal and Direct3D as well, in addition to OpenGL. What is Qt Quick 3D? (and what it is not) Qt Quick 3D is not a replacement for Qt 3D, but rather an extension of Qt Quick’s functionality to render 3D content using a high-level API. Here is what a very simple project with some helpful comments looks like: import QtQuick 2.12 import QtQuick.Window 2.12 import QtQuick3D 1.0 Window { id: window visible: true width: 1280 height: 720 // Viewport for 3D content View3D { id: view anchors.fill: parent // Scene to view Node { id: scene Light { id: directionalLight } Camera { id: camera // It's important that your camera is not inside // your model so move it back along the z axis // The Camera is implicitly facing up the z axis, // so we should be looking towards (0, 0, 0) z: -600 } Model { id: cubeModel // #Cube is one of the "built-in" primitive meshes // Other Options are: // #Cone, #Sphere, #Cylinder, #Rectangle source: "#Cube" // When using a Model, it is not enough to have a // mesh source (ie "#Cube") // You also need to define what material to shade // the mesh with. A Model can be built up of // multiple sub-meshes, so each mesh needs its own // material. Materials are defined in an array, // and order reflects which mesh to shade // All of the default primitive meshes contain one // sub-mesh, so you only need 1 material. materials: [ DefaultMaterial { // We are using the DefaultMaterial which // dynamically generates a shader based on what // properties are set. This means you don't // need to write any shader code yourself. // In this case we just want the cube to have // a red diffuse color. id: cubeMaterial diffuseColor: "red" } ] } } } } The idea is that defining 3D content should be as easy as 2D.  There are a few extra things you need, like the concepts of Lights, Cameras, and Materials, but all of these are high-level scene concepts, rather than implementation details of the graphics pipeline. This simple API comes at the cost of less power, of course.  While it may be possible to customize materials and the content of the scene, it is not possible to completely customize how the scene is rendered, unlike in Qt 3D via the its customizable framegraph.  Instead, for now there is a fixed forward renderer, and you can define with properties in the scene how things are rendered.  This is like other existing engines, which typically have a few possible rendering pipelines to choose from, and those then render the logical scene. A Camera orbiting around a Car Model in a Skybox with Axis and Gridlines (note: stutter is from the 12 FPS GIF ) What Can You Do with Qt Quick 3D? Well, it can do many things, but these are built up using the following scene primitives: Node Node is the base component for any node in the 3D scene.  It represents a transformation in 3D space, and but is non-visual.  It works similarly to how the Item type works in Qt Quick. Camera Camera represents how a scene is projected to a 2D surface. A camera has a position in 3D space (as it is a Node subclass) and a projection.  To render a scene, you need to have at least one Camera. Light The Light component defines a source of lighting in the scene, at least for materials that consider lighting.  Right now, there are 3 types of lights: Directional (default), Point and Area. Model The Model component is the one visual component in the scene.  It represents a combination of geometry (from a mesh) and one or more materials. The source property of the Mesh component expects a .mesh file, which is the runtime format used by Qt Quick 3D.  To get mesh files, you need to convert 3D models using the asset import tool.  There are also a few built-in primitives. These can be used by setting the following values to the source property: #Cube, #Cylinder, #Sphere, #Cone, or #Rectangle. We will also be adding a programmatic way to define your own geometry at runtime, but that is not yet available in the preview. Before a Model can be rendered, it must also have a Material. This defines how the mesh is shaded. DefaultMaterial and Custom Materials The DefaultMaterial component is an easy to use, built-in material.  All you need to do is to create this material, set the properties you want to define, and under the hood all necessary shader code will be automatically generated for you.  All the other properties you set on the scene are taken into consideration as well. There is no need to write any graphics shader code (such as, vertex or fragment shaders) yourself. It is also possible to define so-called CustomMaterials, where you do provide your own shader code.  We also provide a library of pre-defined CustomMaterials you can try out by just adding the following to your QML imports: import QtQuick3D.MaterialLibrary 1.0 Texture The Texture component represents a texture in the 3D scene, as well as how it is mapped to a mesh.  The source for a texture can either be an image file, or a QML Component. A Sample of the Features Available 3D Views inside of Qt Quick To view 3D content inside of Qt Quick, it is necessary to flatten it to a 2D surface.  To do this, you use the View3D component.  View3D is the only QQuickItem-based component in the whole API.  You can either define the scene as a child of the View3D or reference an existing scene by setting the scene property to the root Node of the scene you want to renderer. If you have more than one camera, you can also set which camera you want to use to render the scene.  By default, it will just use the first active camera defined in the scene. Also it is worth noting that View3D items do not necessarily need to be rendered to off-screen textures before being rendered.  It is possible to set one of the 4 following render modes to define when the 3D content is rendered: Texture: View3D is a Qt Quick texture provider and renders content to an texture via an FBO Underlay: View3D is rendered before Qt Quick’s 2D content is rendered, directly to the window (3D is always under 2D) Overlay: View3D is rendered after Qt Quick’s 2D content is rendered, directly to the window (3D is always over 2D) RenderNode: View3D is rendered in-line with the Qt Quick 2D content.  This can however lead to some quirks due to how Qt Quick 2D uses the depth buffer in Qt 5.   2D Views inside of 3D It could be that you also want to render Qt Quick content inside of a 3D scene.  To do so, anywhere where an Texture is taken as a property value (for example, in the diffuseMap property of default material), you can use a Texture with its sourceItem property set, instead of just specifying a file in the source property. This way the referenced Qt Quick item will be automatically rendered and used as a texture. The diffuse color textures being mapped to the cubes are animated Qt Quick 2D items. 3D QML Components Due to Qt Quick 3D being built on QML, it is possible to create reusable components for 3D as well.  For example, if you create a Car model consisting of several Models, just save it to Car.qml. You can then instantiate multiple instance of Car by just reusing it, like any other QML type. This is very important because this way 2D and 3D scenes can be created using the same component model, instead of having to deal with different approaches for the 2D and 3D scenes. Multiple Views of the Same Scene Because scene definitions can exist anywhere in a Qt Quick project, its possible to reference them from multiple View3Ds.  If you had multiple cameras in a scene, you could even render from each one to a different View3D. 4 views of the same Teapot scene. Also changing between 3 Cameras in the Perspective view. Shadows Any Light component can specify that it is casting shadows.  When this is enabled, shadows are automatically rendered in the scene.  Depending on what you are doing though, rendering shadows can be quite expensive, so you can fine-tune which Model components cast and receive shadows by setting additional properties on the Model. Image Based Lighting In addition to the standard Light components, its possible to light your scene by defining a HDRI map. This Texture can be set either for the whole View3D in its SceneEnvironment property, or on individual Materials. Animations Animations in Qt Quick 3D use the same animation system as Qt Quick.  You can bind any property to an animator and it will be animated and updated as expected. Using the QtQuickTimeline module it is also possible to use keyframe-based animations. Like the component model, this is another important step in reducing the gap between 2D and 3D scenes, as no separate, potentially conflicting animation systems are used here. Currently there is no support for rigged animations, but that is planned in the future. How Can You Try it Out? The intention is to release Qt Quick 3D as a technical preview along with the release of Qt 5.14.  In the meantime it should be possible to use it already now, against Qt 5.12 and higher. To get the code, you just need to build the QtQuick3D module which is located here: https://git.qt.io/annichol/qtquick3d What About Tooling? The goal is that it should be possible via Qt Design Studio to do everything you need to set up a 3D scene. That means being able to visually lay out the scene, import 3D assets like meshes, materials, and textures, and convert those assets into efficient runtime formats used by the engine. A demonstration of early Qt Design Studio integration for Qt Quick 3D Importing 3D Scenes to QML Components Qt Quick 3D can also be used by writing QML code manually. Therefore, we also have some stand-alone utilities for converting assets.  Once such tool is the balsam asset conditioning tool.  Right now it is possible to feed this utility an asset from a 3D asset creation tool like Blender, Maya, or 3DS Max, and it will generate a QML component representing the scene, as well as any textures, meshes, and materials it uses.  Currently this tool supports generating scenes from the following formats: FBX Collada (dae) OBJ Blender (blend) GLTF2 To convert the file myTestScene.fbx you would run: ./balsam -o ~/exportDirectory myTestScene.fbx Thiswould generate a file called MyTestScene.qml together with any assets needed. Then you can just use it like any other Component in your scene: import QtQuick 2.12 import QtQuick.Window 2.12 import QtQuick3D 1.0 Window { width: 1920 height: 1080 visible: true color: "black" Node { id: sceneRoot Light { } Camera { z: -100 } MyTestScene { } } View3D { anchors.fill: parent scene: sceneRoot } } We are working to improve the assets generated by this tool, so expect improvements in the coming months. Converting Qt 3D Studio Projects In addition to being able to generate 3D QML components from 3D asset creation tools, we have also created a plugin for our asset import tool to convert existing Qt 3D Studio projects.  If you have used Qt 3D Studio before, you will know it generates projects in XML format to define the scene.  If you give the balsam tool a UIP or UIA project generated by Qt 3D Studio, it will also generate a Qt Quick 3D project based on that.  Note however that since the runtime used by Qt 3D Studio is different from Qt Quick 3D, not everything will be converted. It should nonetheless give a good approximation or starting point for converting an existing project.  We hope to continue improving support for this path to smooth the transition for existing Qt 3D Studio users. Qt 3D Studio example application ported using Qt Quick 3D’s import tool. (it’s not perfect yet) What About Qt 3D? The first question I expect to get is why not just use Qt 3D?  This is the same question we have been exploring the last couple of years. One natural assumption is that we could just build all of Qt Quick on top of Qt 3D if we want to mix 2D and 3D.  We intended to and started to do this with the 2.3 release of Qt 3D Studio.  Qt 3D’s powerful API provided a good abstraction for implementing a rendering engine to re-create the behavior expected by Qt Quick and Qt 3D Studio. However, Qt 3D’s architecture makes it difficult to get the performance we needed on an entry level embedded hardware. Qt 3D also comes with a certain overhead from its own limited runtime as well as from being yet another level of abstraction between Qt Quick and the graphics hardware.  In its current form, Qt 3D is not ideal to build on if we want to reach a fully unified graphics story while ensuring continued good support for a wide variety of platforms and devices ranging from low to high end. At the same time, we already had a rendering engine in Qt 3D Studio that did exactly what we needed, and was a good basis for building additional functionally.  This comes with the downside that we no longer have the powerful APIs that come with Qt 3D, but in practice once you start building a runtime on top of Qt 3D, you already end up making decisions about how things should work, leading to a limited ability to customize the framegraph anyway. In the end the most practical decision was to use the existing Qt 3D Studio rendering engine as our base, and build off of that. What is the Plan Moving Forward? This release is just a preview of what is to come.  The plan is to provide Qt Quick 3D as a fully supported module along with the Qt 5.15 LTS.  In the meantime we are working on further developing Qt Quick 3D for release as a Tech Preview with Qt 5.14. For the Qt 5 series we are limited in how deeply we can combine 2D and 3D because of binary compatibility promises.  With the release of Qt 6 we are planning an even deeper integration of Qt Quick 3D into Qt Quick to provide an even smoother experience. The goal here is that we want to be able to be as efficient as possible when mixing 2D and 3D content, without introducing any additional overhead to users who do not use any 3D content at all.  We will not be doing anything drastic like forcing all Qt Quick apps to go through the new renderer, only ones who are mixing 2D and 3D. In Qt 6 we will also be using the Qt Rendering Hardware Interface to render Qt Quick (including 3D) scenes which should eliminate many of the current issues we have today with deployment of OpenGL applications (by using DirectX on Windows, Metal on macOS, etc.). We also want to make it possible for end users to use the C++ Rendering API we have created more generically, without Qt Quick.  The code is there now as private API, but we are waiting until the Qt 6 time-frame (and the RHI porting) before we make the compatibility promises that come with public APIs. Feedback is Very Welcome! This is a tech preview, so much of what you see now is subject to change.  For example, the API is a bit rough around the edges now, so we would like to know what we are missing, what doesn’t make sense, what works, and what doesn’t. The best way to provide this feedback is through the Qt Bug Tracker.  Just remember to use the Qt Quick: 3D component when filing your bugs/suggestions. The post Introducing Qt Quick 3D: A high-level 3D API for Qt Quick appeared first on Qt Blog. [Less]

As Lars mentioned in his Technical Vision for Qt 6 blog post, we have been researching how we could have a deeper integration between 3D and Qt Quick. As a result we have created a new project, called Qt Quick 3D, which provides a high-level API for ... [More] creating 3D content for user interfaces from Qt Quick. Rather than using an external engine which can lead to animation synchronization issues and several layers of abstraction, we are providing extensions to the Qt Quick Scenegraph for 3D content, and a renderer for those extended scene graph nodes. Does that mean we wrote yet another 3D Solution for Qt?  Not exactly, because the core spatial renderer is derived from the Qt 3D Studio renderer. This renderer was ported to use Qt for its platform abstraction and refactored to meet Qt project coding style. [Less]

7 years ago, Qt 5 was released. Since then, a lot of things have changed in the world around us, and it is now time to define a vision for a new major version. This blog post captures the most important points that can and should define Qt 6.

7 years ago, Qt 5 was released. Since then, a lot of things have changed in the world around us, and it is now time to define a vision for a new major version. This blog post captures the most important points that can and should define Qt 6. Qt 6 ... [More] will be a continuation of what we have been doing in the Qt 5 series and should as such not be disruptive to our users. But a new major version will give us a higher degree of freedom to implement new features, functionality and better support the requirements of today and tomorrow than we currently can within the Qt 5 series. As described in more detail below, Qt 6 will aim for a large degree of compatibility with the Qt 5 series. We are also still working on new versions of Qt 5, and we’re aiming to bring some of the features that will define Qt 6 in a slightly reduced form to Qt 5.14 and Qt 5.15 LTS. With the feature freeze of Qt 5.14, more R&D focus will shift towards Qt 6, and we’re aiming to have Qt 6.0 ready for a first release by the end of 2020. Before we dive into all the things that will be new, let’s also remember some of the core values of Qt for our users, to define the things we don’t want to change. What makes Qt valuable to our users? Qt is a horizontal product that is being used in many different markets. The core values Qt has for our customers and users are: Its cross-platform nature, allowing users to deploy their applications to all desktop, mobile and embedded platforms using one technology and from a single code base Its scalability from low-end, single-purpose devices to high-end complex desktop applications or connected system World-class APIs and tools and documentation, simplifying the creation of applications and devices Maintainability, stability, and compatibility, allowing to maintain large code bases with minimal effort A large developer ecosystem with more than 1 million users A new version of Qt needs to adjust our product to new market demands while keeping the 5 items above at the heart of what we’re doing. The desktop market is at the root of our offering and is a strong and important market for Qt. It is where most of our users get the first contact with Qt and forms the basis of our tooling. Keeping it healthy and growing is a pre-requirement to be able to grow also in other markets. Embedded and connected devices are where we have our biggest growth. Touch screens are coming to an exponentially increasing number of devices, but there is strong pressure on the price point of the hardware for these devices. Low-end chipsets, microcontrollers, combined with small to medium-sized touch screens will be used everywhere. Most of those devices will have relatively simple functionality but require polished and smooth user interfaces. Large volumes of such devices will be created, and we need to ensure we can target that space with our offering to be able to live up our scalability promise. At the same time, user interfaces at the high end of the device spectrum will continue to increase in complexity, containing thousands of different screens and many applications. Merging 2D and 3D elements into one user interface will be common, as will be the usage of augmented and virtual reality. Elements of artificial intelligence will be more commonly used in applications and devices, and we will need to have easy ways to integrate with those. The strong growth in the number of connected devices being created as well as much higher requirements on user experience makes it more important for us to focus on world-class tooling to simplify the creation of applications and devices. Integrating UX designers into the development workflow is one of our goals, but there will be many other areas where we need to try to simplify the lives of our users. Qt 6 will be a new major version for Qt. The main goal with such a new major version is to prepare Qt for the requirements coming in 2020 and beyond, clean up our codebase and make it easier to maintain. As such the focus will be on those items that require architectural changes within Qt and cannot be done without breaking some level of compatibility with Qt 5.x. Below are some of the key changes we need to make in Qt to make it fit for the next years to come. Next-generation QML QML and Qt Quick have been the main technologies fueling our growth over the last years. The intuitive ways of creating User Interfaces using those technologies are a unique selling point of our offering. But QML, as it was created for Qt 5, has some quirks and limitations. This, in turn, means that there is the potential for significant enhancements, that we are planning to implement with Qt 6. The main changes planned here are: Introduce strong typing. Weak typing makes it hard for our users to apply large changes to their codebases. A strong type system allows for IDEs and other tools to support our users in this task and dramatically ease the maintenance. Also, we will be able to generate much better-performing code and reduce overhead. Make JavaScript an optional feature of QML. Having a full JavaScript engine when using QML can complicate things and is an overhead especially when targeting low-end hardware such as microcontrollers. It is however extremely useful in many use cases. Remove QML versioning. By simplifying certain lookup rules in QML and changing the way context properties work, we can remove the need for versioning in QML. This, in turn, will lead to large simplifications in the QML engine, greatly simplify our workload of maintaining Qt Quick and simplify usage of QML and Qt Quick for our users Remove the duplication of data structures between QObject and QMLCurrently, quite some data structures are duplicated between our meta-object system and QML, degrading startup performance and increasing memory usage. By unifying those data structures, we will be able to cut away most of that overhead. Avoid runtime generated data structures. This relates to the point before, where many of those duplicated data structures are currently being generated at runtime. It should be perfectly possible to generate most of them at compile time. Support compiling QML to efficient C++ and native code. With strong typing and simpler lookup rules we can convert QML to efficient C++ and native code, significantly increasing runtime performance Support hiding implementation details. ‘Private’ methods and properties have been a long-time requirement to be able to hide data and functionality in QML components Better tooling integration. Our current code model for QML is often incomplete, making refactoring, and detection of errors at compile time difficult to impossible. With the above changes, it should be possible to offer compile-time diagnostics that can compete with C++, as well as much improved refactoring support. Next-generation graphics A lot of things have changed in the graphics area since we did Qt 5.0, leading to us having to do significant changes to our graphics stack to stay competitive. With Qt 5, we used OpenGL as the unified API for 3D graphics. Since then a host of new APIs have been defined. Vulkan is the designated successor of OpenGL on Linux, Apple is pushing for Metal, and Microsoft has Direct 3D. This means that Qt will in the future have to seamlessly work with all those APIs. To make that possible a new layer abstracting the graphics APIs (like QPA for the platform integration) called the Rendering Hardware Interface (RHI) has to be defined. We will need to base all our rendering infrastructure (QPainter, the Qt Quick Scenegraph, and our 3D support) on top of that layer. The set of different graphics APIs also leads to us having to support different shading languages. The Qt Shader Tools module will help us to cross-compile shaders both at compile and at runtime. 3D is playing a more and more important role, and our current offering doesn’t have a unified solution for creating UIs that contain both 2D and 3D elements. Integrating QML with content from Qt 3D or 3D Studio is currently cumbersome and causes some performance overhead. In addition, it is impossible to sync animations and transitions on a frame by frame level between 2D and 3D content. The new integration of 3D content with Qt Quick is aiming to solve this problem. In this case, a full new renderer will allow rendering 2D and 3D content together and support arbitrary nesting between the two. This will turn QML into our UI definition language for 3D UIs and remove the need for the UIP format. We will provide a technology preview of the ‘new’ Qt Quick with 3D support already with Qt 5.14, more information will come in a separate blog post. Finally, the new graphics stack needs to be supported by a decent pipeline for graphical assets, that allows preparing those at compile time for the target hardware and use cases in question. Convert PNG files to compressed textures, compile many of them into texture atlases, convert shaders and meshes into optimized binary formats and more. We also aim to bring a unified theming/styling engine to Qt 6, which will allow us to get a native look & feel on Desktop and mobile platforms to both Qt Widgets and Qt Quick. Unified and consistent tooling Our graphical tooling to create User interfaces has been split into two with Qt 3D Studio and Qt Design Studio. Additionally, Qt 3D Studio is slightly disconnected from the rest of Qt leading to quite some duplicated efforts. We will unify those by merging the required functionality from Qt 3D Studio back into Design Studio. Design Studio shares a lot of code and the application/plugin framework with Qt Creator allowing for a great design experience and giving us the tools to bridge the gap between designers and developers. The Design tooling also needs good integration with content creation tools such as Photoshop, Sketch, Illustrator, Maya, 3D Max, and others. The developer tooling needs a lot of focus and attention so that we can offer the best in class support for C++, QML, and Python. A unified tooling offering also implies that developers can easily use the design functionality from within Qt Creator and that UX designers can benefit from features of the developer tooling such as compiling a project or on-device testing. QMake as the build system used in Qt 5 has lots of quirks and limitations. For Qt 6, we aim to use CMake as a standard 3rd party build system to build Qt itself. CMake is by far the most widely used build system in the C++ world, and better integration with it is sorely needed. We will continue to support our users on QMake, but not develop it further or use it to build the Qt framework itself. Enhancing our C++ APIs C++ has changed a lot over the last years. While we had to base Qt 5.0 on C++98, we can now rely on C++17 for Qt 6. This implies that C++ offers a lot more functionality out of the box that wasn’t available when we did Qt 5. Our goal with Qt 6 has to be to better integrate with this functionality, without losing backward compatibility. For Qt 6, we aim to make some of the functionality introduced with QML and Qt Quick available from C++. We work towards introducing a new property system for QObject and related classes, integrate the binding engine from QML into the core of Qt and make it available from C++. The new property system and the binding engine will lead to a significant reduction in runtime overhead and memory consumption for bindings and make them accessible for all parts of Qt, not only Qt Quick. Language support With Qt 5.12, we introduced support for Python, and we also added the browser as a new platform through Qt for WebAssembly. Keeping and further extending that cross-platform focus will be an important part of the Qt 6 series after 6.0 has been released. Compatibility with Qt 5 and incremental improvements Compatibility with older versions is extremely important and is a major requirement when we develop Qt 6. There are billions of lines of code written using our framework and any incompatible change we do will thus have a cost for our users. Furthermore, the more work the change to Qt 6 requires from our users the slower the adoption will be, which leads to more cost on our side to maintain the last version of Qt 5. As such, we should aim to avoid breaking Qt in a way that triggers compile-time or runtime errors in our users’ codebase. If we must break compatibility, a compile-time error is preferable over a silent breakage at runtime (as those are much harder to detect). While we do need to remove certain deprecated parts of Qt, we need to ensure that our users have the functionality they require. That implies that key functionality, such as Qt Widgets and other parts used by a large portion of our users, will, of course, stay available. We are planning for many incremental improvements to our core classes and functionality that we could not do in the Qt 5 series. The aim is to keep full source compatibility, but as we can break binary compatibility with Qt 6, we can do quite a lot of cleanups and improvements that couldn’t be done within Qt 5. Nevertheless, we need to move forward, and some house cleaning is required with Qt 6. We will remove most functionality (functions, classes or modules) that have been deprecated in Qt 5. This house cleaning will help free up our developers’ time in the longer term and allow us to have more focus on the maintained and current codebase. Porting away from those deprecated parts does however need to be as simple as possible and our users can ideally do this incrementally using Qt 5.15 LTS. Our goal should be that Qt 6 is compatible enough with Qt 5.15 LTS so that one can easily maintain a large code base that can compile against both versions at the same time. Marketplace & technical product structure In addition to improving the Qt framework and tools, we aim to create a new marketplace for components and development tools. The marketplace will be focused on our direct users developing and designing applications and embedded devices, not targeted at consumers. As such it will be a central rallying point for the Qt ecosystem. It will give 3rd parties a place to publish their additions to Qt, allowing for both free and paid content. Qt has been growing a lot over the last years, to the point where delivering a new version of it is a major undertaking. With Qt 6 there is an opportunity to restructure our product offering and have a smaller core product that contains the essential frameworks and tooling. We will use the market place to deliver our add-on frameworks and tools, not as a tightly coupled bundle with the core Qt product. This will give us additional flexibility on when and how we deliver things and allows us to decouple release schedules for some add-ons. Give us your feedback and get involved The technical vision will evolve further until the first release of Qt 6. While I believe that this document captures many of the most important points for the next version of Qt it is certainly not complete. If you have any further ideas, please get involved in the development of Qt 6 and discussions around it through Qt’s open governance model. The post Technical vision for Qt 6 appeared first on Qt Blog. [Less]

We are happy to announce the release of Qt Creator 4.10 RC ! The prebuilt binaries for this release are based on a Qt 5.13.1 snapshot, which should take care of regular crashes that some of you experienced with the earlier Beta releases. For more ... [More] details on the 4.10 release, please have a look at the blog post for Beta1 and our change log. Get Qt Creator 4.10 RC The 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.10 RC is also available under Preview > Qt Creator 4.10.0-rc1 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.10 RC released appeared first on Qt Blog. [Less]

We are happy to announce the release of Qt Creator 4.10 RC !

As you might have heard Qt is moving away from qmake in favor of CMake. Some people have raised concerns with the fact that CMake generates projects that build in longer time than qmake. For the last couple of weeks I have been busy with improving ... [More] CMake upstream in regards to compilation speed. Precompiled headers Qmake can make use of precompiled headers, while CMake doesn’t have support for them natively. It’s enough to search after “precompiled headers CMake” in your favorite search engine to find tens of projects that provide this functionatily via a CMake module. CMake has a bug report named Support for precompiled headers opened 14 years ago. In his C++Now2017: Effective CMake talk Daniel Pfeifer mentioned that he had a prototype adding precompiled headers support, namely CMake MR 984. At 1h:19m:18s we can see how precompiled headers as usage requirements would look in CMake: target_precompile_headers(Foo PUBLIC "foo.h" PRIVATE His prototype had only support for Visual Studio and Xcode generators, nothing for Ninja or Makefiles. Based on his work I’ve completed CMake MR 3553, which also adds support for Ninja and Makefiles generators. Precompiled headers support in compilers can be split into two categories: Visual C++ style: for a pch.h / pch.c pair you will get two generated files pch.pch and pch.obj. You need to link to the generated pch.obj file. GCC style: for pch.h / pch.h.c pair you will get one generated file pch.h.gch. There is no obj file to link to, and if you try to link to the pch.h.gch file you will get an error. With both styles supported in CMake, I did a CMake build of Qt Creator on my Windows 10 machine running on a Lenovo AMD Ryzen CPU: MinGW GCC 8.1.0 – 22.09% speed-up Visual C++ 2017 – 37.28% speed-up Clang-cl 8.0.0 – 30.66% speed-up The results in a chart: Because every target will get its own precompiled header, the build directory size have changed a bit: The code that I had to write to add precompiled headers support in Qt Creator’s CMake files is here. Note for ccache users: you need to set up ccache sloppiness. Unity (Jumbo) builds While working on adding support for precompiled headers I learned how to add source files internally in the CMake project. Therefore it was easy to come up with unity (jumbo) source files, which include the original source files in batches in form of: #include "source_file1.cpp" #include "source_file2.cpp" /*...*/ #include "source_file8.cpp" The CMake MR 3611 adds support for Unity (Jumbo) Builds in CMake. With precompiled headers one could just change a few CMake lines and get a 20-40% speed increase without changing any source files. With unity builds it’s not always the case. ODR (One Definition Rule) errors are popping up everywhere. Qt Creator’s source code is not compatible with unity builds. I took Speedcrunch for testing. Speedcrunch also doesn’t work out of the box with unity builds. Patch can be found here. Setting up Unity builds with CMake is as easy as passing -DCMAKE_UNITY_BUILD=ON in the CMake command line. The default batch size is 8. I configured Speedcrunch in Release mode, and compiled only the speedcrunch target, and got the results: MinGW GCC 8.1.0 – 29.33% speed-up Visual C++ 2017 – 53.50% speed-up Clang-cl 8.0.0 – 23.61% speed-up The results in a chart: The build directory size is a bit smaller with Unity builds, because of less object files created. Both features are under code review on Kitware side. We can do something about the build times now, until C++20 Modules will change the game. The post Precompiled Headers and Unity (Jumbo) Builds in upcoming CMake appeared first on Qt Blog. [Less]

I have been busy improving the CMake support in Qt Creator for the last couple of weeks and thought I should take the time to highlight some of the new features. Fileapi support The CMake project has announced a new IDE integration mechanism with ... [More] their 3.14 release called fileapi. It provides about the same level of information as the previous recommended mechanism (server-mode), but does not require a long-running cmake process. This makes the new approach use less resources while being more robust in the face of users running cmake on the command line. “fileapi” is now supported in Qt Creator (master branch). Demo of CMake releated features in Qt Creator master CMake support in the Locator Creator has allowed to trigger the build of CMake targets via the locator for a while now. Simply do Ctrl-K to focus the locator and then type cm to build that target. In master branch this got a small extension: Typing cmo will open the definition of a target in the editor. This works best when your CMake binary supports fileapi: It will then take you to the exact line the target is defined at. Older CMake binaries will just open the CMakeLists.txt file in the target’s source directory instead as there is no information on line numbers available. Open targets via the Context menu The same information that is used by the cmo locator is used to populate a Open... menu in the target’s context menu. That allows to jump straight to lines relevant to the target definition. Note that this feature has been available for one specific CMake version with server-mode support before, but the necessary support in CMake got removed again and only returned in the fileapi. That is all I have to show today:-) Please test Qt Creator with CMake 3.14 or later and provide feedback and report bugs. Unfortunately there are currently no snapshots of Qt Creator taken from the master branch, those will only become available after Qt Creator 4.10RC release. Thanks to Alessandro for demoing these features in a short video! The post Update on CMake project support in Qt Creator appeared first on Qt Blog. [Less]