@kkoehne said in CMake +Qt6 +lupdate: cool - sounds to become easier and more flexible in 6.7. will test with beta2 And the NATIVE_TS_FILE option only will actually appear in Qt 6.7: https://doc-snapshots.qt.io/qt6-dev/qtlinguist-cmake-qt-add-translations.html I'm developing always in english, where in most cases german is used by customers. Because I'm writing code in 'developer-english' it may happen, that customer requests to change a translation. for these cases and to handle plural forms I always also add an en ts file, so I'm using .ts / _de.ts / _en.ts / _fr.ts ... this is working well because translations not found in _en.ts will come from .ts seems that in this case I don't have to set the NATIVE_TS_FILE, because _en.ts not only contains plural forms ? if setting QT_I18N_LANGUAGES will this work if my (from Qt 5.15 ported) .ts files are in project_dir/translations ? BTW: the lrelease command is executed automatically if building in QtCreator ? In 5.15 my workflow was: lupdate, Linguist, lrelease Now in 6.7 I can do lupdate automatically with add_dependencies(...lupdate) or execute manually with CMD-K cm ...lupdate and lrelease is always done automagically ?

I just realized that Qt6 is not tested against tvOS specifically and is built against iOS. The latter has wider selection of available frameworks. I guess I'll need to manually Qt for tvOS.

I must answer my own question. Sometimes I miss the obvious. A Settings.bundle is simply a resource and must be copied to the Resources. Since Apple changed the directory chirarchy in the app bundle, all Resources are files or directories in the root directory. After I realized this, it was simple. Here is a small excerpt of my CMakeLists.txt file: set(settings_bundle "Settings.bundle") qt_add_executable(tpanel MANUAL_FINALIZATION ${PROJECT_SOURCES} "${settings_bundle}" ) target_sources(tpanel PRIVATE "${settings_bundle}") set_source_files_properties(${settings_bundle} PROPERTIES MACOSX_PACKAGE_LOCATION Resources) The above code assume, that the Settings.bundle is in the root of the distribution. If this is not the case, then the relative path must be defined as part of the variable settings_bundle. That's it!

I must answer my own question. Sometimes I miss the obvious. A Settings.bundle is simply a resource and must be copied to the Resources. Since Apple changed the directory chirarchy in the app bundle, all Resources are files or directories in the root directory. After I realized this, it was simple. Here is a small excerpt of my CMakeLists.txt file: set(settings_bundle "Settings.bundle") qt_add_executable(tpanel MANUAL_FINALIZATION ${PROJECT_SOURCES} "${settings_bundle}" ) target_sources(tpanel PRIVATE "${settings_bundle}") set_source_files_properties(${settings_bundle} PROPERTIES MACOSX_PACKAGE_LOCATION Resources) The above code assume, that the Settings.bundle is in the root of the distribution. If this is not the case, then the relative path must be defined as part of the variable settings_bundle. That's it!

You have to re-compile Qt specifically for the simulator via -DQT_UIKIT_SDK=iphonesimulator. Possibly forcing different architecture via -DCMAKE_OSX_ARCHITECTURES=arm64.

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

@TheoSys File a bug to Qt and tell them to fix it.

@jsulm I used to believe that the only way to create a C++ GUI was through Qt Design Studio, as I had never created anything in C++ other than console programs. I've created a GUI in Python in the past with it. However, I stumbled upon examples in Qt Creator that use .ui files. I'm familiar with this approach, having worked with UI and widgets before. I believe I'll continue using widgets since they don't show any errors when the program is executed. I will close this conversation as I no longer require assistance with qml. If I encounter any further issues, I'll post on a forum if I'm unable to resolve them myself. Thank you to everyone who tried to help me.

This issue was fixed in Qt Creator 11.0.1.

@Christian-Ehrlicher My bad. Thank you, it worked! I need to up my cmake game...

@timob256 target_link_libraries(${PROJECT_NAME} PRIVATE ${Qt5AxContainer_LIBRARIES}) target_link_libraries(compas_com_example PRIVATE Qt${QT_VERSION_MAJOR}::Core)

you don't need this. Qt 6.7 / QtC 13.0: there are automatically generated targets there, you can execute: update_translations release_translations [image: e68d24d5-128c-4a0f-9dce-7e1682099059.png]

@Christian-Ehrlicher QT Creator, btw I solved by changing the CMake generator in project -> manage kits -> kits :D

@codeform I'm having the same issue. Conan's version of Qt doesn't seem to set the right qt cmake variables. Namely, QT6_IS_SHARED_LIBS_BUILD and QT_DEPLOY_SUPPORT are missing.