Porting QML Applications to Qt 6

When transitioning an application from Qt 5 to Qt 6, there are some smaller changes that may affect your application. Check the following list to see if you need to update your code to be compatible.

Changed type of font.weight

The type of font.weight has been changed to int. The pre-defined weight classes still exist, but it is now possible to use arbitrary integers to select fonts which do not match any of these weight classes. This ensures parity with the C++ API, in which weight has always been expressed by an int.

Most code will be unaffected by this, except in the case where an implicit conversion from a string to enum value was used.

 font.weight: "Bold"

This code will no longer parse correctly and has to be replaced by its equivalent enum value, as demonstrated below.

 font.weight: Font.Bold

Made FontLoader.name a read-only property

In Qt 5, the name property of a FontLoader was writable and would override the source property of the item when set. This caused some confusion as to its purpose and could cause undeterministic behavior if there was a race condition between the setters for the conflicting properties.

In Qt 6, it is no longer possible to set this property. It can only be read. This means that code such as the following will no longer work.

 FontLoader {
     id: fontLoader
     name: "Helvetica"
 }

 Text {
     font.family: fontLoader.name
     text: "Foobar"
 }

Instead, use a custom property to store hardcoded font family names.

 property string fontName: "Helvetica"

 Text {
     font.family: fontName
     text: "Foobar"
 }

The OpenGLInfo QML type has been removed

OpenGLInfo was deprecated in Qt 5.8 due to being superseded by GraphicsInfo. In Qt 6, OpenGLInfo is removed. Use GraphicsInfo instead.

OpenGL is no longer the default choice on some platforms

While it will present no breaks for many applications, application developers should be aware that, OpenGL is not always the default choice anymore for Qt Quick rendering in Qt 6. Unless the software backend is used, a Qt Quick application could use OpenGL, Vulkan, Metal, or Direct3D 11 at run time. When no explicit request is made, either via the QSG_RHI_BACKEND environment variable or the QQuickWindow::setSceneGraphBackend() function, a platform-specific default is chosen by Qt Quick. This is currently Metal on macOS and iOS, Direct3D 11 on Windows, OpenGL elsewhere.

ShaderEffect source properties are now URLs

The ShaderEffect properties vertexShader and fragmentShader both have a type of QUrl now, instead of QByteArray. Their behavior is therefore identical to other similar properties, such as Image.source. Existing code that refers to files via the file or qrc scheme will continue to work as-is. In addition, this change allows referring to files with a path relative to the component's (the .qml file's) location. Specifying the file: scheme is therefore optional now.

ShaderEffect does not support inline GLSL shader strings anymore

Just like with custom materials, the effects are no longer specified in form of GLSL shader strings. Rather, shaders are expected to be preprocessed by the tools from the Qt Shader Tools module, such as the qsb command line tool, thus ensuring the shader assets are usable regardless of which graphics API (Vulkan, Metal, OpenGL, or Direct 3D) is used at run time. ShaderEffect items are expected to reference the resulting .qsb files