I'm losing the will to live. Every time I open a class file in Qt Creator (3.0.1) it hangs for around 20-30 seconds, totally consuming the CPU core that it's running under. I tried changing pre-compiled header settings and deleting old settings files, but it still happens :( So, has anyone had this issue and solved it?
Please upgrade to QtCreator 3.3.0 - here the Qt team reworked the loading to use multiple threads and thus doesn't block the GUI while parsing the source and project files any more.
Related
I've recently installed Ubuntu 22.04 LTS on my development laptop. Previously I was running 18.04 so this is my first experience of Wayland. I did a clean installation on a new disc. I had relatively few problems reinstalling gitkraken and cloning the repository of my source code from github but when I came to install the Qt libraries this is where my problems started. The on-line installer from the Qt website simply wouldn't run. It just exited silently. I eventually found an old version of the on-line installer executable in a backup of my downloads folder from Ubuntu 18.04 and was able to use this to download and install the same version of the Qt libraries that I was using previously (5.15.0). This is also the same version that I use on my other development machine which runs Windows 10. Keeping the two in step is useful and upgrading too many things at the same time seemed like asking for trouble. I installed the latest versions of Qt Creator (7.0.1) and g++ (11.2.0).
I was then able to build my application and, after a brief search of stack overflow I added "-platform wayland" to the command line arguments setting in Qt Creator but the application crashed almost immediately on start-up with the error "The Wayland connection experienced a fatal error: Protocol error".
Several things made me think this might be a bug in the Qt libraries rather than my application (none of them definitive!):
At the point of application exit, apart from main() there is none of my application code in the call-stack (see below)
My application has been stable for a long time and has survived several operating system, compiler and Qt version changes across two OS families
The fact that the latest Qt on-line installer (itself almost certainly a Qt application) wouldn't run
I downloaded Qt 5.15.12 (the latest Qt 5 version available) and rebuilt my application against that but the result was the same.
The next step is obviously to strip my application right down to something minimal that still shows the problem but before I do I was wondering whether this is something other people have come across when migrating a Qt5 application to Wayland and whether I need to take the bigger step of upgrading to Qt6? The Qt Wiki describes Qt 5.11 as being "stable" with Wayland.
The call stack at the time of the error looks like this:
qt_message_fatal
QMessageLogger::fatal
QtWaylandClient::QWaylandDisplay::checkError
QtWaylandClient::QWaylandDisplay::flushRequests
doActive
QMetaObject::activate
QSocketNotifier::activated
QSocketNotifier::event
QApplicationPrivate::notify_helper
QApplication::notify
QCoreApplication::notifyInternal2
QCoreApplication::sendEvent
socketNotifierSourceDispatch
g_main_context_dispatch
??
g_main_context_iteration
QEventDispatcherGlib::processEvents
QEventLoop::exec
QCoreApplication::exec
main
Many thanks.
It's something to do with QDialog::setMaximumSize. The call to setMaximumSize itself does not crash but if I remove all calls to it the application works fine. Some controls do subjectively seem bigger on Wayland so I wonder if Qt 5 on Wayland crashes if the size of the QDialog contents exceeds the maximum size specified. This certainly doesn't cause a crash in Qt 5 on Windows and didn't in Qt 5 on Ubuntu prior to the switch to Wayland. I think this is a Qt bug but of course it may well be fixed in a later version of Qt and there's an easy enough work-around now I know the cause.
I was using setMaximumSize to allow the dialog to expand dynamically as widgets were added but to prevent the user from making the window any bigger than it needed to be. layout()->setSizeConstraint(QLayout::SetFixedSize); achieves the same thing.
I'm trying to set up the environment on the new machine for our application written on Qt15.2 with GCC compiler version 10.2, and because it is a windows application, I get the qt and gcc from the MSYS2.
The compiling process is going well, but when I'm trying to launch the application, it crashes with the message: "the program has unexpectedly finished. the process was ended forcefully"
The same I obtained if trying to compile a blank qml app with a single ApplicationWindow in it.
I will be very grateful for your help.
The solution was found - I used "dependencies" (https://github.com/lucasg/Dependencies) to find out, which .dll libraries are missing. The problem was in some Windows libraries because it was a fresh system downloaded from Microsoft site without any updating made yet and seems to be very old. I had updated the system and everything is working fine now.
I have a Qt 4.8-based application that runs on Windows 7 and uses Qt Assistant to display documentation. I've frequently had headaches with Qt Assistant relating to the need to delete cached files whenever I update documentation (I keep reading that cache problems have been fixed in various Qt updates, but the problems I have seem to persist). This occurs when I launch Assistant from within my application or directly from the command line (with assistant.exe -collectionFile myapp.qhc).
This is a major problem when I'm distributing my application to users. It's not OK to expect them to delete cached files on their systems.
I couldn't find anything in the Qt documentation on how to clear the user's cached help files. Is there something I'm missing?
I have also compiled my application for Linux, and don't seem to have the same problem there. It's just Windows.
I'm getting crazy with a bad memory access in a qt program when i'm using qglwidget::rendertext function. My program is super simple, I'm only one pointer, but the crash doesn't seem relate to that because the debugger stops sometimes when i call rendertext, sometimes when i close the programs. i'm not experienced c++ programmer and this is getting me crazy.
but i've found this BUG REPORT. It seems recent (Updated: 25/Apr/13 8:47 AM) and due to the fact I don't know what to do with this bad memory access i think it worths to give it a try.
the solution patch is posted here but i don't know what to do.. do i have to recompile all qt 4.8? only the opengl part? can i avoid to recompile everything?
Go to the directory where you compiled Qt and change the file qt/src/opengl/qpaintengine_opengl.cpp. Make the changes that the author made, or download the author's file and replace it in your source directory. Change directory to the main qt directory and run make. Be sure not to re-run ./configure before you do the make or it will rebuild the whole thing.
After make has finished, run sudo make install and it will put the newly compiled QPaintEngine module into your install directory. Unfortunately, I don't know if this will work if you have a number of configurations (like static libraries), but it's worth a try.
I have done this with modules in QtMobility hundreds of times. You also have to remember that you have a Frankenstein's Monster version of Qt now, and when you upgrade remember to re-patch if the change was not committed to the newest build.
Hope this helps.
I just tried running a program that I've been developing with Qt outside of Qt. I double clicked on the program in /release, resolve all the missing DLLs, and find that my app has awful slow performance compared to when it is launched from within Qt Creator. What might be the reason for this?!
Well, I have never encountered this. Is there any files you are loading in your application which is big enough to make the application load slow? Like reading a big flat file and get the contents out of it. If so, just make sure that the file's contents hasn't changed while you were running through Qt Creator and when you run it outside. It's my guess though. For me, the performances doesn't have much differences in either cases.