Improve documentation

* Added reference to ProcessMonitor documentation
* Consistently used term "System-UI"

Change-Id: Ibd41dd38c2140abba85676f98a5e09a25ca706a1
Reviewed-by: Robert Griebl <robert.griebl@pelagicore.com>

14 files changed, 72 insertions, 72 deletions

diff --git a/doc/apps.qdoc b/doc/apps.qdoc
index ebcdff7f..5a14779f 100644
--- a/doc/apps.qdoc
+++ b/doc/apps.qdoc
@@ -60,7 +60,7 @@ supported for convenience, as well. Here are a few things to consider:
         QT_WAYLAND_DISABLE_WINDOWDECORATION is set) and will be invisible by default. QQuick
         \l{Item}{Items} will be wrapped inside a \l Window representing a Wayland client window.
     \li In single-process mode \l Window root elements will appear parallel to instead of inside
-        the system UI.
+        the System-UI.
 \endlist
 
 \section2 The Manifest and Updating the Database
diff --git a/doc/configuration.qdoc b/doc/configuration.qdoc
index 02d1394f..03479244 100644
--- a/doc/configuration.qdoc
+++ b/doc/configuration.qdoc
@@ -188,7 +188,7 @@ all your imports paths and file references relative to your main config file.
     \li \b -I
     \br \e ui/importPaths
     \li array<string>
-    \li Adds additional QML import paths to the system UI.
+    \li Adds additional QML import paths to the System-UI.
 \row
     \li \b -
     \br \e ui/style
@@ -202,7 +202,7 @@ all your imports paths and file references relative to your main config file.
         The value must be a list of plugin library file path names. A single plugin will also be
         accepted. Currently the only valid key is \c startup. The plugin itself must implement the
         \c StartupInterface. The application-manager will call the function hooks during startup of
-        the system UI.
+        the System-UI.
 \row
     \target system properties
     \li \b -
@@ -241,7 +241,7 @@ all your imports paths and file references relative to your main config file.
     \li \b --load-dummydata
     \br \e ui/loadDummyData
     \li bool
-    \li Loads QML dummy-data into the system UI (just like \c qmlscene would).
+    \li Loads QML dummy-data into the System-UI (just like \c qmlscene would).
 \row
     \target no-security
     \li \b --no-security
diff --git a/doc/introduction.qdoc b/doc/introduction.qdoc
index acb56b54..73b6cc15 100644
--- a/doc/introduction.qdoc
+++ b/doc/introduction.qdoc
@@ -97,7 +97,7 @@ using standard compliant mechanism.
 
 \section1 Application Installation
 
-In addition to applications that are part of the system-ui or the base installation (\e built-in), the
+In addition to applications that are part of the System-UI or the base installation (\e built-in), the
 application-manager also supports applications that can be dynamically installed, updated and
 deinstalled (\e third-party).
 
diff --git a/doc/singlevsmultiprocess.qdoc b/doc/singlevsmultiprocess.qdoc
index 3d014c1b..1509f2cc 100644
--- a/doc/singlevsmultiprocess.qdoc
+++ b/doc/singlevsmultiprocess.qdoc
@@ -32,18 +32,18 @@
 
 Single-process mode is only supported by QML applications: applications that use the \c qml or
 \c qml-inprocess runtime. Consequently the comparison between single- and multi-process mode only
-applies to this kind of applications. In multi-process mode the system UI (compositor) and the
+applies to this kind of applications. In multi-process mode the System-UI (compositor) and the
 applications each run in their own dedicated process. In single-process mode, as the name implies,
-there is only one process: the system UI process and all applications run within this process.
+there is only one process: the System-UI process and all applications run within this process.
 
 For a better understanding of the two modes, here is how QML works internally: in every process
 (aka. address-space), you can only have one Qt platform (QPA) plugin. The QPA plugin decides how
 many top-level windows you can open. If you are using a low-level plugin that does not talk to a
 windowing system (e.g. EGL full-screen on an embedded device), you can only open one full-screen
-window - the system UI. Now every top-level window can only have one scene-graph and every tree of
+window - the System-UI. Now every top-level window can only have one scene-graph and every tree of
 QtQuick items needs to be tied to exactly one scene-graph. This means that you will always have
-exactly one window, one scene-graph and one QML engine in your system UI, no matter whether
-applications run within the system UI process or in separate processes.
+exactly one window, one scene-graph and one QML engine in your System-UI, no matter whether
+applications run within the System-UI process or in separate processes.
 
 
 \section1 Single-process Mode
@@ -75,7 +75,7 @@ disabled explicitly by adding the option \c {-config force-single-process}. On t
 step will fail.
 
 In case the application-manager supports only single-process, QML applications that use the \c qml
-runtime will always run in-process, i.e. in the same process as the system UI. Native applications
+runtime will always run in-process, i.e. in the same process as the System-UI. Native applications
 will be omitted in this case, since they can only run in a dedicated process (of course, native
 applications can also use QML code). The difference is basically the entry point: \c native
 runtimes have an executable and \c qml runtimes a main QML file. For the latter the
@@ -85,12 +85,12 @@ If the application-manager is built with multi-process support, it can still be
 single-process-mode by passing \c --force-single-process on the command line. This will result in
 the same runtime behavior as described above. Even when running the application-manager in
 multi-process mode it does not necessarily mean that QML applications get a dedicated process: if
-they use the \c qml-inprocess runtime they will execute in-process within the system UI.
+they use the \c qml-inprocess runtime they will execute in-process within the System-UI.
 
 
 \section1 Configuration
 
-Since there is only one QML engine in single-process mode shared by the system UI and all
+Since there is only one QML engine in single-process mode shared by the System-UI and all
 applications, any QML import paths provided (e.g. through am-config.yaml) will be considered when
 resolving import statements. Import statements provided by an application manifest file (info.yaml)
 will only be considered once the application has been started, but will outlive its "termination".
@@ -108,8 +108,8 @@ Also note that some configuration options are meaningless in single-process mode
 \section1 Lifetime
 
 The most obvious difference is that a crashing application in single-process mode will terminate
-the entire program, whereas in multi-process mode the system UI and other applications keep on
-running. In multi-process mode the system UI even gets notified when an application crashed and
+the entire program, whereas in multi-process mode the System-UI and other applications keep on
+running. In multi-process mode the System-UI even gets notified when an application crashed and
 can react on it, e.g. by restarting the application.
 
 The usage of QML singletons in an application has some implications. In the QML world, singletons
@@ -124,7 +124,7 @@ multi-process case, where the singleton is instantiated anew.
 \section1 ApplicationManagerWindow
 
 A major difference between single- and multi-process mode is how windows are represented. Windows
-are exposed from the application to the system UI through WindowManager::windowReady. For
+are exposed from the application to the System-UI through WindowManager::windowReady. For
 convenience and to serve as a replacement for qmlscene, it is possible to use plain QML Windows in
 applications or even an Item as the root element. However, if close resemblance between single-
 and multi-process mode is the goal, there is no way around using an ApplicationManagerWindow. There
@@ -150,12 +150,12 @@ the different base classes:
     Items will influence the effective visibility of it in single-process mode, whereas in
     multi-process mode only the Window hierarchy is considered (Items are ignored). This behavior
     is not application-manager specific, it is inherent in QtQuick already.
-\li An ApplicationManagerWindow is exposed to the system UI in two different ways: in multi-process
+\li An ApplicationManagerWindow is exposed to the System-UI in two different ways: in multi-process
     mode a handle to the window's content surface is sent over the process boundary via the Wayland
-    protocol. The system UI gets this as a surface Item, which is hierarchically independent from
+    protocol. The System-UI gets this as a surface Item, which is hierarchically independent from
     the application's window. In single-process mode the ApplicationManagerWindow is simply an Item
-    which is provided (through another proxy Item) to the system UI. Consequently, it would be
-    possible to gain access from the system UI to the ApplicationManagerWindow and vice versa.
+    which is provided (through another proxy Item) to the System-UI. Consequently, it would be
+    possible to gain access from the System-UI to the ApplicationManagerWindow and vice versa.
 \li Many properties, functions and signals defined in a Window are not reimplemented (yet) in the
     single-process version of ApplicationManagerWindow.
 \li An error encountered in a code block due to properties or methods described above will cause
@@ -164,7 +164,7 @@ the different base classes:
 \li In single-process mode, if the ApplicationManagerWindow is loaded dynamically via a Loader,
     setting the loader to inactive will destruct the ApplicationManagerWindow immediately and hence
     there is no possibility to play a window closing animation. In multi-process mode there is
-    still the surface Item available on the system UI side, which can be animated.
+    still the surface Item available on the System-UI side, which can be animated.
 \endlist
 
 
@@ -181,8 +181,8 @@ mode only one.
 
 The CPU memory consumption per application is higher due to additional data structures, for
 instance if one application is running there are two instances of the QML engine in multi-process
-mode: one for the system UI and one for the application. In single-process mode there is only one
-instance since everything is running within the system UI. Also assets might be duplicated in
+mode: one for the System-UI and one for the application. In single-process mode there is only one
+instance since everything is running within the System-UI. Also assets might be duplicated in
 multi-process mode. This can be mitigated though, by using shared image providers or by removing
 images from CPU memory once they are uploaded to GPU memory (through environment variable
 QSG_TRANSIENT_IMAGES).
@@ -196,7 +196,7 @@ stopped again. The QML engine simply doesn't allow to unload parts of the object
 
 \section1 Recommended Way to Support Mixed Setups
 
-Define a set of inter-process communication (IPC) interfaces between the application and system UI
+Define a set of inter-process communication (IPC) interfaces between the application and System-UI
 and stick to them - make this a review policy. You could use any IPC mechanism you see fit, but to
 make your lives easier, the application manager comes with an IPC mechanism that already fully
 abstracts the single- vs. multi-process difference, plus it makes it easy to create new interfaces
@@ -205,6 +205,6 @@ for QML developers.
 Please be aware that the application-manager IPC is not suitable to interface your complete
 middle-ware! Its sole purpose is to avoid a whole zoo of little one-off daemons that would be
 needed to keep track of different pieces of state information that need to be shared between the
-system UI and all (or best case, only specific) applications.
+System-UI and all (or best case, only specific) applications.
 
 */
diff --git a/examples/minidesk/doc/images/minidesk.png b/examples/minidesk/doc/images/minidesk.png
index 45bcde4b..0a16982a 100644
--- a/examples/minidesk/doc/images/minidesk.png
+++ b/examples/minidesk/doc/images/minidesk.png
diff --git a/examples/minidesk/doc/src/minidesk.qdoc b/examples/minidesk/doc/src/minidesk.qdoc
index b9311ff5..989e0b2d 100644
--- a/examples/minidesk/doc/src/minidesk.qdoc
+++ b/examples/minidesk/doc/src/minidesk.qdoc
@@ -28,14 +28,14 @@
 /*!
 
 \example minidesk
-\title Desktop System UI Example
+\title Desktop System-UI Example
 \image minidesk.png Screenshot
-\brief Minimal Desktop System UI in pure QML
+\brief Minimal Desktop System-UI in pure QML
 \ingroup applicationmanager-examples
 
 \section1 Introduction
 
-The \e {Desktop System UI Example} showcases the application-manager API in a simple fashion. The
+The \e {Desktop System-UI Example} showcases the application-manager API in a simple fashion. The
 focus is on the concepts, less on elegance or completeness, for instance no error checking is done.
 Some features will only print debug messages without further functionality. A classic desktop with
 server-side window decorations is emulated.
@@ -46,20 +46,20 @@ The following features are supported:
 \li Stop applications by clicking on the top/left window decoration rectangle
 \li Raise applications by clicking on the decoration
 \li Drag windows by pressing on the window decoration and moving
-\li System UI sends 'propA' change when an app is started
-\li System UI and App2 react on window property changes with a debug message
+\li System-UI sends 'propA' change when an app is started
+\li System-UI and App2 react on window property changes with a debug message
 \li App1 animation can be stopped and restarted by a click
-\li App1 sends 'rotation' property to system UI on stop
-\li App1 shows a pop-up on the system UI while it is paused
+\li App1 sends 'rotation' property to System-UI on stop
+\li App1 shows a pop-up on the System-UI while it is paused
 \li App2 will make use of an IPC extension when it is started
 \li App2 logs the document URL it has been started with
-\li App2 triggers a notification in the system UI when the bulb icon is clicked
+\li App2 triggers a notification in the System-UI when the bulb icon is clicked
 \li A separate (\"wayland\") process started outside of appman will be shown as App1
 \endlist
 
 \note The example can be run in single- and multi-process mode. In the following, multi-process is
 assumed and corresponding terminology is used. The terms \e client and \e application, respectively
-\e server and \e {system UI} are used interchangeably. The system UI comprises compositing and
+\e server and \e {System-UI} are used interchangeably. The System-UI comprises compositing and
 generic inter-process communication (IPC).
 
 \section2 Invocation
@@ -78,7 +78,7 @@ path/to/bin/appman -c am-config.yaml -r --start-session-dbus
 
 \section1 Walkthrough
 
-\section2 System UI Window
+\section2 System-UI Window
 
 \quotefromfile minidesk/system-ui/main.qml
 \skipto import Qt
@@ -87,7 +87,7 @@ path/to/bin/appman -c am-config.yaml -r --start-session-dbus
 \dots
 
 The \l{QtApplicationManager} module has to be imported to be able to access the application-manager
-APIs. The system UI window has a fixed size and linen background color. Instead of a \l{Rectangle},
+APIs. The System-UI window has a fixed size and linen background color. Instead of a \l{Rectangle},
 the root element could as well be a \l{Window}. On top of the background the
 \l{minidesk/system-ui/Readme.qml}{Readme} element is shown that displays a usage how-to. At the
 bottom left there is a textual indication for whether the application-manager runs in single- or
@@ -95,10 +95,10 @@ multi-process mode.
 
 \section2 Launcher
 
-\printto System UI chrome for applications
+\printto System-UI chrome for applications
 
 A \l{Repeater} provides the application icons arranged in a \l{Column} on the top-left corner of
-the system UI. This is achieved by using the \l{ApplicationManager} element as the model. Amongst
+the System-UI. This is achieved by using the \l{ApplicationManager} element as the model. Amongst
 others, it provides the \c icon role which is used as the \l{Image} source URL. The \c icon URL is
 defined in the \l{Manifest Definition}{info.yaml} file of the application. To indicate that an
 application has been launched, the opacity of the corresponding application's icon is decreased
@@ -113,9 +113,9 @@ for the first application). Both applications will be started with the (optional
 \c appContainter will be set below in the \c onWindowReady handler. The content is provided by the
 two applications in an \l{ApplicationManagerWindow} root element.
 
-\section2 Application Windows in the System UI
+\section2 Application Windows in the System-UI
 
-\printto System UI for a pop-up and notification
+\printto System-UI for a pop-up and notification
 
 This second \l{Repeater} provides the window chrome for the actual applications in its delegate.
 The model is the same as for the first \l{Repeater}, essentially the \l{ApplicationManager}
@@ -139,16 +139,16 @@ element. The chrome consists of:
 
 \section2 Pop-ups
 
-Two approaches are implemented to display pop-ups in the system UI:
+Two approaches are implemented to display pop-ups in the System-UI:
 \list
 \li Through a window rendered by the client application
 \li Through the notification API provided by the application-manager
 \endlist
-This is the corresponding system UI code:
+This is the corresponding System-UI code:
 \printto Handler for WindowManager signals
 
 \section3 Client Application Rendering
-The \c popUpContainer \l{Item} provides a system UI recipient for the pop-up rendered
+The \c popUpContainer \l{Item} provides a System-UI recipient for the pop-up rendered
 by App1. App1 instantiates another \l{ApplicationManagerWindow} for the pop-up within its
 \l{ApplicationManagerWindow} root element, as shown here:
 \quotefromfile minidesk/apps/tld.minidesk.app1/app1.qml
@@ -159,12 +159,12 @@ by App1. App1 instantiates another \l{ApplicationManagerWindow} for the pop-up w
 The \l{ApplicationManagerWindow::setWindowProperty}{ApplicationManagerWindow.setWindowProperty()}
 method is used to set a freely selectable shared property. Here we choose \c{type: "pop-up"} to
 indicate that the window is supposed to be shown as a pop-up. In the \c onWindowReady handler below
-the system UI checks for this property and handles the window appropriately as a pop-up.
+the System-UI checks for this property and handles the window appropriately as a pop-up.
 
 \section3 Notification API Usage
 
 An alternative to the above approach is to use the application-manager's \l{Notification} API on
-the application (client) side and the \l{NotificationManager} API on the system UI (server) side.
+the application (client) side and the \l{NotificationManager} API on the System-UI (server) side.
 The following code is invoked when the \e bulb icon of App2 is clicked:
 
 \quotefromfile minidesk/apps/tld.minidesk.app2/app2.qml
@@ -173,7 +173,7 @@ The following code is invoked when the \e bulb icon of App2 is clicked:
 
 App2 creates a new \l{Notification} element, sets its \l{Notification::summary}{summary} property
 and calls \l{Notification::show()}{show()} on it. This call will increase the
-\l{NotificationManager::count}{NotificationManager.count} on the system UI side, and subsequently
+\l{NotificationManager::count}{NotificationManager.count} on the System-UI side, and subsequently
 the \l{Text} element's text property will be set to the \c summary string of the first
 notification. Presenting the first notification only is a simplification to keep the code short.
 
@@ -182,15 +182,15 @@ notification. Presenting the first notification only is a simplification to keep
 \quotefromfile minidesk/system-ui/main.qml
 \skipto Handler for WindowManager signals
 \printto IPC extension
-This is the vital part of the system UI, where the window surfaces of the applications are mapped
-to items in the system UI. The \l {WindowManager::windowReady}{onWindowReady} handler is invoked
+This is the vital part of the System-UI, where the window surfaces of the applications are mapped
+to items in the System-UI. The \l {WindowManager::windowReady}{onWindowReady} handler is invoked
 when a new application window is shown (visibility set to true). The \c index parameter references
 into the \l{WindowManager} model, which holds the window surfaces. The first line translates this
 index to the application index of the \l{ApplicationManager} model and assigns it to \c appIndex.
 
 Only the "pop-up" ApplicationManagerWindow of App1 has the user-defined \c type property set. All
 other windows don't have the \c type property. In the latter case, the application's \c window
-passed to \c onWindowReady is re-parented to the system UI's \c winChrome. Also the size of the
+passed to \c onWindowReady is re-parented to the System-UI's \c winChrome. Also the size of the
 window is set to fill the entire \c appContainer.
 
 There is a special treatment for an invalid \c appIndex for demonstration purposes: it is assumed
@@ -203,7 +203,7 @@ QT_WAYLAND_DISABLE_WINDOWDECORATION=1 ./qtapp -platform wayland
 
 This application will then be shown inside the App1 container.
 \c QT_WAYLAND_DISABLE_WINDOWDECORATION is set to disable client side window decorations, since they
-are provided by the system UI. Note, that an application started in this way, can just as well be
+are provided by the System-UI. Note, that an application started in this way, can just as well be
 closed only from the command line.
 
 Pop-ups (windows with type "pop-up") are re-parented to their respective \c popUpContainer.
@@ -217,7 +217,7 @@ with the \c window.
 
 \section2 IPC Extension
 The following snippet demonstrates how the \l{ApplicationIPCInterface} can be used to define an IPC
-extension. The IPC interface has to be defined in the system UI, for instance:
+extension. The IPC interface has to be defined in the System-UI, for instance:
 \printuntil Component.onCompleted
 \printline }
 
@@ -240,7 +240,7 @@ to match the name it was registered with in
 \l{ApplicationIPCManager::registerInterface()}{ApplicationIPCManager.registerInterface()}.
 
 \section2 Application Termination
-When an application is stopped from the system UI through
+When an application is stopped from the System-UI through
 \l{ApplicationManager::stopApplication()}{ApplicationManager.stopApplication()}, it will be sent
 the \l{ApplicationInterface::quit()}{ApplicationInterface.quit()} signal. The application can do
 some clean-up and must subsequently confirm with
diff --git a/examples/minidesk/system-ui/Readme.qml b/examples/minidesk/system-ui/Readme.qml
index 23c00ead..e07fcf72 100644
--- a/examples/minidesk/system-ui/Readme.qml
+++ b/examples/minidesk/system-ui/Readme.qml
@@ -65,7 +65,7 @@ Item {
             id: heading
             color: "cornflowerblue"
             font { pixelSize: 20; weight: Font.Bold }
-            text: "Minimal Desktop System UI in pure QML"
+            text: "Minimal Desktop System-UI in pure QML"
         }
 
         Text {
@@ -77,14 +77,14 @@ Item {
                   "\u2022 Stop applications by clicking on the top/left window decoration rectangle\n" +
                   "\u2022 Raise applications by clicking on the decoration\n" +
                   "\u2022 Drag windows by pressing on the window decoration and moving\n" +
-                  "\u2022 System UI sends 'propA' change when an app is started\n" +
-                  "\u2022 System UI and App2 react on window property changes with a debug message\n" +
+                  "\u2022 System-UI sends 'propA' change when an app is started\n" +
+                  "\u2022 System-UI and App2 react on window property changes with a debug message\n" +
                   "\u2022 App1 animation can be stopped and restarted by a click\n" +
-                  "\u2022 App1 sends 'rotation' property to system UI on stop\n" +
-                  "\u2022 App1 shows a pop-up on the system UI while it is paused\n" +
+                  "\u2022 App1 sends 'rotation' property to System-UI on stop\n" +
+                  "\u2022 App1 shows a pop-up on the System-UI while it is paused\n" +
                   "\u2022 App2 will make use of an IPC extension when it is started\n" +
                   "\u2022 App2 logs the document URL it has been started with\n" +
-                  "\u2022 App2 triggers a notification in the system UI when the bulb icon is clicked\n" +
+                  "\u2022 App2 triggers a notification in the System-UI when the bulb icon is clicked\n" +
                   "\u2022 A separate (\"wayland\") process started outside of appman will be shown as App1"
         }
     }
diff --git a/examples/minidesk/system-ui/main.qml b/examples/minidesk/system-ui/main.qml
index 29d1eeae..055dc1e4 100644
--- a/examples/minidesk/system-ui/main.qml
+++ b/examples/minidesk/system-ui/main.qml
@@ -86,7 +86,7 @@ Rectangle {
         }
     }
 
-    // System UI chrome for applications
+    // System-UI chrome for applications
     Repeater {
         id: windows
         model: menuItems.model
@@ -131,7 +131,7 @@ Rectangle {
         }
     }
 
-    // System UI for a pop-up and notification
+    // System-UI for a pop-up and notification
     Item {
         id: popUpContainer
         z: 30000
diff --git a/examples/monitor/doc/src/monitor.qdoc b/examples/monitor/doc/src/monitor.qdoc
index 6ca9919b..ca3c9902 100644
--- a/examples/monitor/doc/src/monitor.qdoc
+++ b/examples/monitor/doc/src/monitor.qdoc
@@ -67,14 +67,14 @@ We will start from the bottom, because this is the essential part.
 \printline }
 The ProcessMonitor is an instantiatable type that will monitor the process that is associated with
 its \l {ProcessMonitor::applicationId}{applicationId} property. An empty applicationId string means
-that the system-UI process is monitored. By clicking the "Switch Process" button, the monitored
+that the System-UI process is monitored. By clicking the "Switch Process" button, the monitored
 process can be changed to the \c tld.monitor.app application. Measurements will be performed each
 second (1000 ms) and 12 reading points will be kept in the model (the ProcessMonitor is a model).
 The model is used below to display the bar charts.
 
 Memory and frame rate reporting need to be enabled, since we are interested in both. For frame rate
 measurements the list of \c monitoredWindows has to be filled with windows that we are interested
-in. For the system-UI this is the single root window itself and for the tld.monitor.app process it
+in. For the System-UI this is the single root window itself and for the tld.monitor.app process it
 is the currently selected window. Hence the list will always include just one element. The memory
 and frame rate changed signal handlers will update the current values of the corresponding views.
 
@@ -87,7 +87,7 @@ the model (the SystemMonitor is a model, as well).
 
 The very last line will start the only application that is provided by this example. Note that, if
 the application-manager is running in single-process mode, the application will run within the
-system-UI process and consequently the ProcessMonitor will not report anything and the associated
+System-UI process and consequently the ProcessMonitor will not report anything and the associated
 ProcessMonitor::processId will be set to 0.
 
 \section2 The User Interface
diff --git a/src/common-lib/startuptimer.cpp b/src/common-lib/startuptimer.cpp
index bebf0ae1..87769b5a 100644
--- a/src/common-lib/startuptimer.cpp
+++ b/src/common-lib/startuptimer.cpp
@@ -106,7 +106,7 @@
         #color-blue   { background-color: #5454ff; color: #000000 }
     </style>
     <pre>
-<span id="color-orange">== STARTUP TIMING REPORT: System UI ==</span>
+<span id="color-orange">== STARTUP TIMING REPORT: System-UI ==</span>
 <span id="color-green">0'110.001</span> entered main                                <span id="color-blue">   </span>
 <span id="color-green">0'110.015</span> after basic initialization                  <span id="color-blue">   </span>
 <span id="color-green">0'110.311</span> after sudo server fork                      <span id="color-blue">   </span>
diff --git a/src/main-lib/main.cpp b/src/main-lib/main.cpp
index 22cbf951..7c25f8f6 100644
--- a/src/main-lib/main.cpp
+++ b/src/main-lib/main.cpp
@@ -669,7 +669,7 @@ void Main::showWindow(bool showFullscreen)
             QObject::disconnect(conn);
 #  endif
             StartupTimer::instance()->checkFirstFrame();
-            StartupTimer::instance()->createReport(qSL("System UI"));
+            StartupTimer::instance()->createReport(qSL("System-UI"));
         }
     });
 
diff --git a/src/manager-lib/applicationmanager.cpp b/src/manager-lib/applicationmanager.cpp
index e431f1b4..79b1ddde 100644
--- a/src/manager-lib/applicationmanager.cpp
+++ b/src/manager-lib/applicationmanager.cpp
@@ -1031,7 +1031,7 @@ bool ApplicationManager::openUrl(const QString &urlStr)
 
     if (!apps.isEmpty()) {
         if (!isSignalConnected(QMetaMethod::fromSignal(&ApplicationManager::openUrlRequested))) {
-            // If the system-ui does not react to the signal, then just use the first match.
+            // If the System-UI does not react to the signal, then just use the first match.
             startApplication(apps.constFirst(), urlStr, mimeTypeName);
         } else {
             ApplicationManagerPrivate::OpenUrlRequest req {
diff --git a/src/monitor-lib/processmonitor.cpp b/src/monitor-lib/processmonitor.cpp
index 0f94ffb9..02725294 100644
--- a/src/monitor-lib/processmonitor.cpp
+++ b/src/monitor-lib/processmonitor.cpp
@@ -51,7 +51,7 @@
 
     The ProcessMonitor type provides statistics about the resource usage and performance for a process known to the
     application-manager. Currently, CPU load, memory usage and frame rate can be monitored. This type is
-    available in the system-UI only.
+    available in the System-UI only.
 
     The ProcessMonitor is dedicated to Linux in particular, since this is currently the only OS
     that supports multi-process mode. Other OS's are supported only rudimenatary.
@@ -180,7 +180,7 @@
     This property holds the OS specific process identifier (PID) that is monitored. This can be
     used by external tools for example. The property is 0, if there is no process associated with
     the \l applicationId. In particular, if the application-manager runs in single-process mode,
-    only the system-UI (identified by an empty \l applicationId) will have an associated process.
+    only the System-UI (identified by an empty \l applicationId) will have an associated process.
 */
 
 /*!
@@ -188,7 +188,7 @@
 
     The ID of the application that will be monitored. It must be one of the ID's known to the
     application-manager (\l ApplicationManager::applicationIds provides a list of valid IDs). There
-    is one exception: if the ID is set to an empty string, the system-UI process will be monitored.
+    is one exception: if the ID is set to an empty string, the System-UI process will be monitored.
     Setting a new value will reset the model.
 */
 
@@ -236,8 +236,8 @@
     signal and the WindowManager type is itself a model which holds all windows of all
     application processes.
 
-    \note It is possible to monitor server side (system-UI) views, as well,
-    if the \l applicationId is empty (hence the system-UI process will be monitored).
+    \note It is possible to monitor server side (System-UI) views, as well,
+    if the \l applicationId is empty (hence the System-UI process will be monitored).
     Those windows are available from QML since they need to be registered with
     \l {WindowManager::registerCompositorView(QQuickWindow *view)} {WindowManager}
     and can be assigned to \l monitoredWindows.
diff --git a/src/window-lib/windowmanager.cpp b/src/window-lib/windowmanager.cpp
index 989bf8b9..0dc9661e 100644
--- a/src/window-lib/windowmanager.cpp
+++ b/src/window-lib/windowmanager.cpp
@@ -869,7 +869,7 @@ void WindowManager::waylandSurfaceDestroyed(WindowSurface *surface)
 
     emit windowLost(index, win->windowItem()); //TODO: rename to windowDestroyed
 
-    // Just to safe-guard against the system-ui not releasing windows. This could lead to severe
+    // Just to safe-guard against the System-UI not releasing windows. This could lead to severe
     // leaks in the graphics stack and it will also prevent clean shutdowns of the appman process.
     int timeout = 2000;
     if (slowAnimations())