What's New

Qt ApplicationManager 6.8

The ApplicationInterface root context property was the last bit in the application manager that was still not using declarative registration. Starting with 6.8, the ApplicationInterface is implemented as an attached type that can attach to anything. This new mechanism is fully source compatible with the previous one, but now also supports modern QML tooling.

All D-Bus socket names and paths for both the application manager's "auto" session bus, as well as the peer-to-peer busses for each application have changed. They now live in $XDG_RUNTIME_DIR instead of /tmp (if available) and they are created in the sub-directories qtapplicationmanager-session and qtapplicationmanager-runtime respectively. This should only affect you, if you are using hard coded paths in a container setup.

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:

• NotificationModel will now complement the existing ApplicationModel and IntentModel classes.
• The application manager now comes with a bubblewrap container integration: this uses the bubblewrap utility to create a new kernel namespace and runs the requested binary in this sandbox isolated from the rest of the system. This is the base technology used in the Linux Flatpak ecosystem. See the Bubblewrap Container Example for an example setup with test applications.

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.