Okay, I reinstall Qt fully, thankfully I managed to setup android back again without any pain. Surprisingly, on windows all tools take less space, than on macOS, only 40ish gigs. Problem now fixed, although the original reason is unknown.
Have you removed/ensured there are no existing breakpoints left over from before?
Did you do a "clean" and complete rebuild?
Sounds like it is doing some kind of "search" for something first time. Try running it under gdb directly outside of Creator? You might try running strace gdb to see what it seems to be doing during the delay?
Hi and welcome to devnet,
This is not the Qt Creator support team, this is a user forum.
As for GStreamer and Qt 6. You might want to take a look at their qml6glsink.
Thanks for the comments. So I don't think there's anything wrong with the code itself. It seems to be a configuration with Qt Creator and clangd that is ignoring the c++17 specification in the .pro file.
I found a previous post about this issue, and how they fixed it: https://forum.qt.io/topic/109856/incompatible-with-c-98-warnings-since-qt-creater-update/3
But that post is 5 years old, and none of the options they used to fix the issue exist in in the current Qt Creator.
@MiC78 said in Qt Creator debugger is slow:
Do not ask me why they were there.
If you just open up projects in QtCreator they are opened inside the default session. Sessions in Qt Creator never forget anything. In order to not carry over any breakpoints (or bookmarks) from other projects, create a new session for each project (and then later open the sessions and not the projects).
@Blackzero Since it wasn't there even though I restarted Qt Creator, I finally added it myself, I thought it was a bug in Qt Creator.
[image: d29fa65d-af8d-4ac5-a4af-2656f81aa740.png]
@Axel-Spoerl said in Disable showing the xml of edited .ui files:
What else? After all, the ui file is currently open. What should be opened in the editor instead? Should it remain empty?
Actually yes, or just let it be at the state it was before (any cpp file that was opened before).
The XML file is what is actually processed during compilation. It may even be interesting for some to check.
I think the times one wants to go back to actual code that was worked on before outweighs the times of wanting to have a look at the underlying xml by far. The problem is that once you go back to text edit mode the projects explorer selects the opened ui/xml file and now i have to rethink on where my initial file was. @TomZ is right, if want to look at the xml i can still do this explicitly, but opening an ui file twice in the texteditor and in the designer per default is just an annoying experience.
@Christian-Ehrlicher I could, but they are massive, and generated traversing the deps folder recursively as I've realised, it's not "just" the root.
Anyway, I'll look into fixing the underlying issue which likely is some rpaths that need fixing - thanks!
