Qt Creator and other tools

Ha, I got Jira to work. I'll keep an eye on the issue, thanks a lot!

@Robert-Hairgrove Fair enough. If it were me I would try a quick one line Qt GUI program of my own to see whether it respects --qwindowgeometry (that's one of the command line arguments any Qt program picks up), plus save/restore if you're wanting to check that, to see where you start from.

Hi, Which version of Qt Creator are you talking about ?

I have the same problem but in windows 10... did you find any solution ?

@galkinvv Thanks for your workaround for this. It got me up and running. According to this We should be able to use mount-libexec and libexec-mount-point for this. However, I tried them and they don't work. Have you found out anything more about this? Kevin

[Using QtCreator 18.0.2 and Qt 6.7.2] I had the same issue and I solved it by adding "NO_CACHEGEN" under "qt_add_qml_module" in my CMakeLists.txt file. As far as I understand, this problem occurs because the Preview uses the file under build folder but your changes occur on your projects file (which are not exactly the same file) and this tag disables caching and thus solves the problem. qt_add_qml_module(appXXX URI XXX VERSION 1.0 NO_CACHEGEN

@hskoglund Using a timer can be anything between a waste of time and vain hope. It depends on the operating system, how showMaximized(), showNormal() and the like are handled. QWidget::windowState() reflects what has been ordered to the window manager. The problem is that the widget's geometry can change twice. First time when showMaximized() has been processed and widget->windowState().testFlag(Qt::WindowMaximized) returns true. Second time, when the window manager has applied decorations (i.e. title bar and window handles). A good place to look for inspiration is tst_QWidget::showMaximized() and showFullScreen(). The QTRY_ macros generally process events until either the predicate is true or a timeout is hit. They're not available in applications, but you can write your own methods that work for your use case.

@Andy314 and @Udo-Alt I tried to reproduce the problem, but could not reproduce this bug. Can one of you give exact instructions with sample code to reproduce this problem? Then it would be possible to create a fix. Regards

@JYG61 See "Topics Tools" at the top

Qodeassist is so much better

Update Qt Creator conan mechanism In file c:\Qt\Tools\QtCreator_v20\share\qtcreator\cmake-helper\package-manager.cmake in line 115 (file(WRITE "${CMAKE_BINARY_DIR}/conan-dependencies/CMakeLists.txt" ") generates CMakeLists.txt with hardcoded default profile A little bit higher set(PROFILE_FILE "") if (CONAN_HOST_PROFILE OR CONAN_BUILD_PROFILE) if (CONAN_HOST_PROFILE) set(PROFILE_FILE "${PROFILE_FILE} -pr:h \"${CONAN_HOST_PROFILE}\"") endif() if (CONAN_BUILD_PROFILE) set(PROFILE_FILE "${PROFILE_FILE} -pr:b \"${CONAN_BUILD_PROFILE}\"") endif() else() set(PROFILE_FILE "-pr:a \"${CMAKE_BINARY_DIR}/conan-dependencies/conan_host_profile\"") endif() and substitute in line 134 (before adding above lines) from -pr \\"${CMAKE_BINARY_DIR}/conan-dependencies/conan_host_profile\\" to "${PROFILE_FILE}".

I needed to rework the patch in https://codereview.qt-project.org/c/qt-creator/qt-creator/+/725372 So Creator 20 will work out of the box, if you have Git 2.31.0 or newer. If you can only use older Git versions, you need to set core.quotepath false in local or global a git config file. Regards

The following appears to work, but is it the correct way to do it? qt_add_translations(${PROJECT_NAME} TS_FILE_DIR i18n PLURALS_TS_FILE i18n/${PROJECT_NAME}_en.ts PLURALS_TS_FILE i18n/${PROJECT_NAME}_en_GB.ts QM_FILES_OUTPUT_VARIABLE qm_files ) qt_add_resources(${PROJECT_NAME} "kernel_translations" PREFIX "/i18n" BASE "${CMAKE_CURRENT_BINARY_DIR}" FILES ${qm_files} )

The plot thickens... I cleaned out the entire build directory, including what I thought might have been a stale .qmake.stash file. After building everything successfully from scratch, I introduced an error by intentionally misspelling one of the variables in a function in MySource.cpp. Tried to compile that single file and got the same error as reported above. So I corrected the error, right-clicked once more on the file name in the "Projects" view, and now I have this error: :-1: error: No rule to make target '.obj/MySource.o'. Stop. Once again, I click on the main "Build" icon on the bottom left, and everything successfully compiles and links. I tried to make a minimal project to reproduce the error, but I cannot pin it down. It doesn't seem to have anything to do with the presence of the OBJECTS_DIR variable. It could be that the source file is in a subproject of the main project which has TEMPLATE=subdirs. But the subproject is TEMPLATE=app. And this did work for many years (i.e. compiling a single file from the "Projects" view context menu). Something has broken recently.