What's New

Qt ApplicationManager 6.7

The application manager now has full support for QML tooling (like compilation) for System UIs and applications. The application-features example was adapted to makes use of these new features. In order to achieve this, large parts of the QML object implementations had to be rewritten. This means that some APIs are no longer backwards-compatible. We tried to keep the changes to a minimum and provide compatibility aliases where possible, but some changes were unavoidable.

The most important change is that ApplicationManagerWindow is now derived from QObject in both single- and multi-process applications (before it was derived from FocusScope in single-process mode and Window in multi-process mode). While there are negative and positive implications for multi-process applications, these include a lot of benefits for single-process or mixed-mode applications, where there is now a consistent API with a lot more common functionality for all cases:

  • The new API closely mirrors Qt's existing Window API, including the attached properties.
  • Tracking the window's active state and its activeFocusItem is now supported also in single-process mode.
  • Embedding an ApplicationManagerWindow into another one similar to the preliminary Window::parent mechanism is not supported yet.
  • There still is full access to the backingObject (Window or Item) if needed.

There are also changes to the private C++ API that might affect you if you are implementing plugins and custom appman or launcher executables:

  • Defines for configurable features (e.g. AM_MULTI_PROCESS) have been removed, as the same functionality is already available via Qt's feature macro (e.g. QT_CONFIG(am_multi_process)).
  • As the application manager supports building against older Qt versions (down to the latest LTS release), you now also get application manager specific version defines similar to the Qt ones (QT_AM_VERSION{,_STR,_MAJOR,_MINOR,_PATCH}).
  • The module Qt::AppManLauncherPrivate was renamed to Qt::AppManApplicationMainPrivate and the class LauncherMain to ApplicationMain to better reflect their purpose: this module started as the basis for the QML launcher but evolved into a generic building block for launchers as well as native applications alike.

In addition, here are some additional, noteworthy changes:

  • The Bubblewrap Container plugin is now a lot more flexible when it comes to kernel namespace (un)sharing.
  • Setting up quick-launching for multiple runtimes and containers is much more flexible now.
  • The ApplicationInstaller singleton that was deprecated in 5.14 has now finally been removed.
  • Along the same lines, dummy-data support was removed. This had been done for the qml and qmlscene tools already in Qt 6.3.
  • A new tool named appman-package-server has been added that takes over the role of the deprecated companion project Qt Automotive Suite Deployment Server. As with the deprecated project, this is not meant to be an app store backend for production, but rather an easy to use tool for developers or CI environments to test and verify package installations. This also comes with a new example.

Qt ApplicationManager 6.6

Two new features have been added:

In addition, there have been some changes in functionality:

  • The IntentServerHandler::visibility property now defaults to Public instead of Private, the same way as it works for client-side intent definitions in an app's manifest file.
  • QML applications will now quit immediately when requested to via ApplicationManager::stopApplication(), if no handler is connected to the ApplicationInterface::quit() signal. These applications would have been force-terminated only after a 250msec timeout before.
  • The quick launch mechanism can now detect broken runtime/container combinations and will disable them instead of re-trying to start them in an infinite loop. This can be fine tuned via the new failedStartLimit and failedStartLimitIntervalSec configuration parameters.
  • In order to support JavaScript's strict mode, the package role of the PackageManager singleton had to be renamed to packageObject, as package is a reserved JS keyword in strict mode. The old package role is still available in non-strict mode. All the other singleton models got a similar *Object alias role to keep the APIs consistent.

Qt ApplicationManager 6.3

The APIs and manifest definitions concerning the Package, Application and Intent fields for icon, name and description have been cleaned up. All three support the same API now, with the package's fields acting as a fallback for both the application and intent objects. Due to a clash between the property name and the function name in ApplicationObject, user code that called the Application.name(language) function before, now needs to replace this with Application.names[language].

Qt Application Manager 6.2

No new APIs were added, but the build system switched from qmake to CMake and the deprecated legacy ApplicationInterfaceExtension IPC mechanism was finally removed. A direct replacement for the old IPC had been added in 5.14 already in form of the new Intents mechanism.

© 2024 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.