1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
// Copyright (C) 2023 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\page whatsnew.html
\ingroup qtappman
\title What's New
\brief Important changes in Qt Application Manager
\section1 Qt ApplicationManager 6.9
Due to a behavior change in the QtWaylandCompositor module, the "not visible" state on windows does
not lead to a loss of the backing surface anymore. Before 6.9, hiding a visible window
(setting ApplicationManagerWindow::visible to \c false) would lead to WindowObject::contentState
being set to \c NoSurface. From 6.9 onwards, hiding a window sets the
\l{WindowObject::}{contentState} to \c SurfaceNoContent instead.
This also affects the WindowManager model, as hidden windows are \b not removed from the model
anymore. You can still \l{WindowObject::}{close} windows or simply destroy the client-side
ApplicationManagerWindow instance to force a \c NoSurface state.
Because we cannot emulate this behavior change in neither a forward nor backward compatible way,
Qt Application Manager 6.9 cannot be built against Qt < 6.9 and Qt Application Manager 6.8 cannot
be built against Qt > 6.8.
This change makes a lot of sense though and it brings the Qt implementation in line with other
Wayland toolkits as well as all the other platform plugins in Qt itself.
Historical note: QtWaylandCompositor versions before 5.8 behaved exactly like 6.9 is now, but the
implementation was changed in 5.8 due to the \e xdg_shell specification at that time not allowing
this kind of hide mechanism.
Other noteworthy changes in this release:
\list
\li The StartupTimer reports have been improved to show both absolute and relative time
durations.
\li A new monitoring component (FrameContentTracker) was added to help with tracking down
invisible animations that lead to performance issues due to constant rendering.
\endlist
\section1 Qt ApplicationManager 6.8
Continuing the theme of the last release, this version improves on the QML tooling support:
\list
\li The \c 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.
\li All \c requestId parameters and properties on IntentRequest and IntentServer have been
changed from \c uuid to \c string, as the QML engine does not support uuids directly
(instead any QUuid is implicitly wrapped in a QVariant). This change is source compatible
on the JS side though.
\endlist
These new features have been added:
\list
\li The very simple Wayland surface based watchdog mechanism has been replaced with a fully
configurable watchdog mechanism that watches the main thread's event loop, the render thread
of any Quick window, as well as Wayland clients. See \l{Watchdog} for more information.
Please keep in mind that the new Wayland watchdog is disabled by default, whereas the old
one was enabled by default, using hardcoded timeout values (1s check interval / 2s kill
timeout).
\endlist
In addition, here are some additional, noteworthy changes:
\list
\li 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 \c
$XDG_RUNTIME_DIR instead of \c /tmp (if available) and they are created in the
sub-directories \c qtapplicationmanager-session and \c qtapplicationmanager-runtime
respectively. This should only affect you, if you are using hard coded paths in a container
setup.
\li The \c installationLocations configuration field that was deprecated in 5.14 was finally
removed.
\li All examples have been modernized: support for QMake has been removed and they now all use
CMake's QML support to create compiled modules. This means that the simple examples will
not run directly from the source directory out of the box anymore using the \c appman
binary as a runtime (like \c qml and \c qmlscene).
You can still start them this way, but you have to manually specify the location of the
\c apps folder via the \c --builtin-apps-manifest-dir command line option.
\endlist
\section1 Qt ApplicationManager 6.7
The application manager now has full support for QML tooling (like compilation) for System UIs
and applications. The \l{Application Features Example}{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 \l FocusScope in
single-process mode and \l 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:
\list
\li The new API closely mirrors Qt's existing \l{Window} API, including the attached properties.
\li Tracking the window's \l{ApplicationManagerWindow::}{active} state and its
\l{ApplicationManagerWindow::}{activeFocusItem} is now supported also in single-process mode.
\li Embedding an ApplicationManagerWindow into another one similar to the preliminary
Window::parent mechanism is not supported yet.
\li There still is full access to the \l{ApplicationManagerWindow::}{backingObject} (\l Window
or \l Item) if needed.
\endlist
There are also changes to the private C++ API that might affect you if you are implementing plugins
and custom appman or launcher executables:
\list
\li Defines for configurable features (e.g. \c AM_MULTI_PROCESS) have been removed, as the same
functionality is already available via Qt's feature macro (e.g.
\c {QT_CONFIG(am_multi_process)}).
\li 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 (\c{ QT_AM_VERSION{,_STR,_MAJOR,_MINOR,_PATCH} }).
\li The module \c Qt::AppManLauncherPrivate was renamed to \c Qt::AppManApplicationMainPrivate
and the class \c LauncherMain to \c 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.
\endlist
In addition, here are some additional, noteworthy changes:
\list
\li The \l{Bubblewrap Container} plugin is now a lot more flexible when it comes to kernel
namespace (un)sharing.
\li Setting up quick-launching for multiple runtimes and containers is
\l{runtimes-per-container}{much more flexible now}.
\li The ApplicationInstaller singleton that was deprecated in 5.14 has now finally been removed.
\li Along the same lines, dummy-data support was removed. This had been done for the \c qml and
\c qmlscene tools already in Qt 6.3.
\li A new tool named \l{Package-Server}{appman-package-server} has been added that takes over
the role of the deprecated companion project
\l{https://doc.qt.io/QtAutoDeploymentServer/index.html}{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 \l{Package Installation Example}{example}.
\endlist
\section1 Qt ApplicationManager 6.6
Two new features have been added:
\list
\li NotificationModel will now complement the existing ApplicationModel and IntentModel classes.
\li The application manager now comes with a \c bubblewrap container integration: this uses the
\l{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
\l{Flatpak}{Linux Flatpak ecosystem}. See the \l {Bubblewrap Container Example} for an
example setup with test applications.
\endlist
In addition, there have been some changes in functionality:
\list
\li The IntentServerHandler::visibility property now defaults to \b Public instead of
\b Private, the same way as it works for client-side intent definitions in an app's manifest
file.
\li 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.
\li 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 \c failedStartLimit and \c failedStartLimitIntervalSec configuration parameters.
\li In order to support JavaScript's \e strict mode, the \c package role of the PackageManager
singleton had to be renamed to \c packageObject, as \c package is a reserved JS keyword in
strict mode. The old \c package role is still available in non-strict mode. All the other
singleton models got a similar \c *Object alias role to keep the APIs consistent.
\endlist
\section1 Qt ApplicationManager 6.3
The APIs and manifest definitions concerning the Package,
Application and Intent fields for \c icon, \c name and \c 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 \c name and the function \c name in ApplicationObject,
user code that called the \c{Application.name(language)} function before, now needs to replace
this with \c{Application.names[language]}.
\section1 Qt Application Manager 6.2
No new APIs were added, but the build system switched from qmake to CMake and
the deprecated legacy \c 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 \l{Intents}
mechanism.
*/
|
