Why does my QML application window appear as a separate window (on Windows only)
-
I'm not sure if this is a build question or a Qt Quick question.
My app has a single application window and this behaves as you'd expect when I run it locally from Qt Creator on Windows or Mac (and also on iPad when packaged for iOS and installed via the App Store or TestFlight).
However once it has been packaged, code signed and installed as an app on Windows, its behaviour is different: when I start the app, it shows the splash screen and then instead of the app appearing in the same window, it's appearing in a separate window.
To be clear, I am not creating a splash screen myself or using a class like
QSplashScreen
. As part of packaging a Windows app, you provide an app manifest and associated assets, which contain icons and aSplashScreen.png
image. It's this that's appearing and weirdly remaining separate from my app.Any ideas?
In
Main.qml
my root object isWindow
.In
main.cpp
:#include <QGuiApplication> #include <QQmlApplicationEngine> int main(int argc, char* argv[]) { QGuiApplication app(argc, argv); QQmlApplicationEngine engine; const QUrl url(u"qrc:/Primary/Main.qml"_qs); QObject::connect(&engine, &QQmlApplicationEngine::objectCreationFailed, &app, []() { QCoreApplication::exit(-1); }, Qt::QueuedConnection); engine.load(url); return app.exec(); }
Notes
- The full test app is on Github: https://github.com/paulmasri/Qt6-CMake-QML
- The app is built in Qt 6.5 with CMake
-
For anyone coming across this thread, the answer is...
tl;dr: You need to add the
runFullTrust
capability.With Qt 5, there was support for UWP apps. This made it possible for Windows apps to be delivered through the Microsoft Store. (This is how my app was built and delivered.)
Then Microsoft opened up the Microsoft Store for Win32 apps too; i.e. standard desktop apps. As a developer you have a choice of either packaging your own installer and delivering that through the Microsoft Store, or just your app, letting Microsoft Store handle installation. The latter option behaves more like the handling of a UWP app and Microsoft handles the code-signing certificate for you.
As a consequence, Qt decided to drop support for UWP as of Qt 6. This was done with no public notification to the Qt community 🤬, with just a message on the Qt development mailing list. I eventually found this out via a convoluted bug report.
What Qt themselves did not realise is that if you submit a Win32 app via the Microsoft Store, because it is a desktop app and does not sit nicely in a sandbox like a UWP app, you need to add the
runFullTrust
capability. If you don't do this, you get the weird behaviour of the application window opening in a separate window described above.However be aware that when you add
runFullTrust
Microsoft will require you to justify why your app needs access to the whole Windows system. I was able to pass certification with a message along the lines of "My app is built with the Qt framework that only generates Win32 apps. My app does not operate outside the sandbox and behaves nicely."One more gotcha if you're going this route. The path
QStandardPaths::AppDataLocation
was different for UWP apps than Win32 apps. The following only applies if you had a UWP app in Qt 5 and stored data there as the path will be wrong for your Win32 app in Qt 6. To fix this, I use the following: https://gist.github.com/paulmasri/75dcd3386a4e8eaf705058240ef547d1 -
I'm wondering if the answer is related to
Window
propertiesflags
,modality
and possiblyvisibility
. I've read the docs but some of it is a little thin on the ground and I am unclear how these properties interact.Can anyone suggest what's needed for my app to be:
- standard iPad app, which means single window that's fullscreen, and
- single-window app on Windows and MacOS
I've been controlling whether my app is fullscreen by setting
visibility: Window.FullScreen
. I still want to have the option to set this or not set this. (Or a different way to start / go into / out of full screen mode for Windows & MacOS.) -
For anyone coming across this thread, the answer is...
tl;dr: You need to add the
runFullTrust
capability.With Qt 5, there was support for UWP apps. This made it possible for Windows apps to be delivered through the Microsoft Store. (This is how my app was built and delivered.)
Then Microsoft opened up the Microsoft Store for Win32 apps too; i.e. standard desktop apps. As a developer you have a choice of either packaging your own installer and delivering that through the Microsoft Store, or just your app, letting Microsoft Store handle installation. The latter option behaves more like the handling of a UWP app and Microsoft handles the code-signing certificate for you.
As a consequence, Qt decided to drop support for UWP as of Qt 6. This was done with no public notification to the Qt community 🤬, with just a message on the Qt development mailing list. I eventually found this out via a convoluted bug report.
What Qt themselves did not realise is that if you submit a Win32 app via the Microsoft Store, because it is a desktop app and does not sit nicely in a sandbox like a UWP app, you need to add the
runFullTrust
capability. If you don't do this, you get the weird behaviour of the application window opening in a separate window described above.However be aware that when you add
runFullTrust
Microsoft will require you to justify why your app needs access to the whole Windows system. I was able to pass certification with a message along the lines of "My app is built with the Qt framework that only generates Win32 apps. My app does not operate outside the sandbox and behaves nicely."One more gotcha if you're going this route. The path
QStandardPaths::AppDataLocation
was different for UWP apps than Win32 apps. The following only applies if you had a UWP app in Qt 5 and stored data there as the path will be wrong for your Win32 app in Qt 6. To fix this, I use the following: https://gist.github.com/paulmasri/75dcd3386a4e8eaf705058240ef547d1 -
-