User suggestion to revamp Qt Application Manager

User wanted to bring up a revamp suggestions for Qt Application Manager:
"
To use WebEngineView in an application running in a Qt Application Manager environment demands that it is run with the native run-time as opposed to the qml run-time.

This is because it requires some prior setup in a main.cpp "before QGuiApplication is created and before window's QPlatformOpenGLContext is created."
https://doc.qt.io/qt-6/qml-qtwebengine-webengineview.html#initializing-web-engine

Additionally for our specific use case, we need to also need to set:
qputenv("QTWEBENGINE_CHROMIUM_FLAGS", "--no-sandbox");

Having a main.cpp means using the native run-time, and this means that none of the Qt Application Manager APIs can be used within that application, e.g. those that allow it to communicate with the rest of the systemUI or its other applications, critically:
- Intents
- WindowProperties
- Notifications

This is because of a number of reasons:

a) the application manager's libraries are not designed for developers to add to target_link_libraries()
b) the type registration is not done as per Qt6 declarative paradigm and relies on certain code paths being executed (by the qml-runtime or appman itself)

Ideally it should work whatever code you run - for example: qmlscene doesn't do any type registration for you or pre-suppose any of the content. This is made possible because you can import any type and use it, so long as you can:
a) find the package (you can't do this for app man)*
b) add your target_link_libraries (you can't do this for app man)*
c) import the types in your QML and use them - fully qmlsc, qmllint compliant.

(* well, not easily anyway - I have searched in the source code and made my own helper .cmake include to do these manually)

Qt Application Manager does not follow these rules.
a) and b) are not supposed to be done by the developer and c) only works properly if you use the qml run-time which supplies all these symbols for you (unlike qmlscene which doesn't).

Since we have a customer project requirement to use WebEngineView, we are now facing some blocking challenges with this particular feature.

For the environment variable, I investigated using the YAML to set it rather than in the main.cpp:

- id: com.mycompany.ourapp
runtimeParameters: {
environmentVariables: {
"QTWEBENGINE_CHROMIUM_FLAGS": "--no-sandbox-yaml-test"
}
}

But alas any attempt in that application to "qgetenv" the same yields an empty string.
(Note: setting it in Qt Creator as a global appman wide env var does work but not desirable here).

For the c++ calls:

QCoreApplication::setAttribute(Qt::AA_ShareOpenGLContexts);
QtWebEngineQuick::initialize();
... 

there's nowhere else to put this since appman doesn't have a user-editable cpp file for bootstrapping.

Here's a concrete use case:
- a user navigates to one of our (internal) sites and clicks a download link. We handle the download callback in QML / JS as normal but we want to show a notification of the download progress in the system ui.
The API is there to do it, but we are unable to use it because we have to use the native run-time, because we need a main.cpp for setting up the WebEngineView.

App man should work like any other qml module. If I want a QtQuick3D::View3D then I place one in my scene and get a new 3D rendering pipeline.
It would be good therefore to be able to do the same for the app man compositor, and have full control over the top-level main.cpp.
A significant advantage is that CMake then has a top level application to build and link everything against, having a full build tree. With appman as it stands, there is no complete build tree so it is very difficult to ensure that a target_link_libraries (for any other modules) are set up correctly. We have to create our own artificial build tree to ensure it instead which is not very ideal.

"