The news about CERN switching some of their systems from RHEL to Debian due to exactly this reason is not uninteresting in this context.

@JonB OK, for future readers here's the code I ended up with. It's a lot simpler than all the hallucinations provided by Google. I'm pretty sure it's not the canonical way to do this but it works and I'll continue studying the links provided in this thread. import sys from PySide6.QtCore import QFile from PySide6.QtWidgets import QApplication, QVBoxLayout, QWidget from PySide6.QtUiTools import QUiLoader def load_ui(ui_file_path: str) -> QWidget: loader = QUiLoader() ui_file = QFile(ui_file_path) if not ui_file.open(QFile.ReadOnly): print("Cannot open ui file") sys.exit(-1) ui = loader.load(ui_file) ui_file.close() return ui class MainWindow(QWidget): def __init__(self, ui:QWidget): super().__init__() self.ui = ui self.setWindowTitle("My Qt Designer App") layout = QVBoxLayout(self) layout.setContentsMargins(0, 0, 0, 0) layout.addWidget(ui) # Load comboBox items #ui.comboBox.addItems(getLoginCandidates(dbEngine)) ui.pushButton.clicked.connect(self.on_submit_clicked) def on_submit_clicked(self): print("The button was clicked!") if __name__ == "__main__": app = QApplication(sys.argv) ui = load_ui("../ui/test.ui") window = MainWindow(ui) window.show() rc = app.exec() sys.exit(rc)

isnt there a widget signal blocker that stops signals while manipulating manually

@Richard-Moe-Gustavsen said in StyleKit: comparing performance against Qt Style Sheets is on our to-do list Other than performance, it's also worth comparing the usability of StyleKit vs. style sheets. I remember getting quite frustrated with style sheets before and had to fight hard to make things look exactly how I want. I've yet to do a deep dive into StyleKit, but from a quick glance it seems more intuitive+flexible and less "surprising" than style sheets.

Excellent ! Good luck :-)

@JKSH I've made some progress - merged my changes from QtSvg 6.10 into 6.12. Also tried rebase (on a separate copy), but rebasing is a separate sorcery skill I clearly do not possess at the moment. The merged version builds, but my CMakeUserPresets got lost somewhere in the merging, and now Qt Creator builds everything in the repo/build directory. A minor inconvenience, but tolerable. Running tests and examples against the new build (and ensuring they are run against the new build) needs more time. I remember trying my previous CMake build with a custom LD_LIBRARY_PATH to ensure it uses the right stuff. Maybe it will be applicable in this case as well. Qt Creator likely has env variables somewhere in the Project settings, haven't explored those yet. The AI that I poke with different stupid questions also suggests that I can try ldd /path/to/your/example | grep Svg to verify that the example/test will use the correct library before running it. I'll circle back to this thread when I have more info to share.

Hi, quick update after further investigation. I upgraded from Visual Studio 2019 to Visual Studio 2022 (Thanks to @hskoglund), and this gave me much more detailed Edit and Continue diagnostics. These logs made the issue much clearer. What I found This does not appear to be a Qt runtime memory leak. The bottleneck is in the MSVC Edit-and-Continue/hot reload patching workload when large executable translation units are edited. For the same type of edit in source.cpp: Legacy setup (Qt3-era project): ~1,542 sections processed ~1 MB remapped patch apply time ~0.3 s Qt6.8.3 setup (VS2022, x64, C++17): ~11,050 sections processed ~67 MB remapped hundreds of modified/new sections (including many unwind/PDATA-related sections) patch apply time ~25 s So the slowdown/crash pattern is strongly correlated with: very large source files in executable entry modules, and much larger ENC delta/metadata in modern Qt6/C++17 builds. Important detail I can Edit-and-Continue my central libraries repeatedly without issue. The failures happen mostly when modifying very large executable source files (10k+ lines). Current conclusion This looks like a size-dependent MSVC ENC limitation/fragility (address-space fragmentation/exhaustion during repeated remapping), rather than a Qt API feature issue. If anyone has practical mitigation experience for large x64 Qt6 projects (compiler/linker/debug settings, ENC-friendly code organization, etc.), I’m very interested. Thanks again for all suggestions.

@aha_1980 good point ! I did not think of the snapshots.

@DuBu your model will not update in your qml gui without Q_OBJECT macro in TableModel. I did not change anything in your code and it works on ubuntu .

@DSpUz my laptop was bad so i couldnt reply

You can reproduce it inside docker. I've checked out v6.12.0-beta1 tag into $PWD/qt. docker run -it --rm -v $PWD/qt:/src/qt ubuntu:22.04 bash export CMAKE_VERSION="4.3.2" export DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y \ build-essential \ perl \ python3 \ git \ ninja-build \ cmake \ ccache \ libssl-dev \ checkinstall \ libwayland-dev \ libxrandr-dev \ patchelf \ wget \ fuse3 \ pkg-config \ rsync \ libharfbuzz-dev \ libfribidi-dev \ libfontconfig-dev \ libgl1-mesa-dev \ libx11-dev \ libxext-dev \ libxfixes-dev \ libxi-dev \ libxrender-dev \ libxcb1-dev \ libx11-xcb-dev \ libxcb-glx0-dev \ libxcb-keysyms1-dev \ libxcb-image0-dev \ libxcb-shm0-dev \ libxcb-icccm4-dev \ libxcb-sync-dev \ libxcb-xfixes0-dev \ libxcb-shape0-dev \ libxcb-randr0-dev \ libxcb-render-util0-dev \ libxcb-util-dev \ libxcb-xinerama0-dev \ libxkbcommon-dev \ libxkbcommon-x11-dev \ libxcb-xinput-dev \ libegl1-mesa-dev \ libxkbfile-dev \ libxtst-dev \ libxshmfence-dev \ libxcursor-dev \ libxcomposite-dev \ libdrm-dev \ libxcb-dri3-dev \ libxcb-cursor-dev \ libxcb-res0-dev \ libdbus-1-dev \ libdbus-c++-dev \ libzstd-dev \ liblzma-dev \ libbz2-dev \ gettext \ python3-pip \ flex \ bison \ libudev-dev \ libcanberra-dev \ qpdf \ xxd \ libavcodec-extra \ libavcodec-dev mkdir /cmake-build && \ cd /cmake-build && \ git clone --depth 1 --branch v${CMAKE_VERSION} https://github.com/Kitware/CMake.git && \ cd CMake && \ mkdir build && \ cd build && \ cmake .. -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release && \ cmake --build . --parallel && \ checkinstall --install=no --nodoc --pkgname=cmake --pkgversion=${CMAKE_VERSION} -y && \ apt -y remove cmake cmake-data && \ dpkg -i cmake_${CMAKE_VERSION}*.deb && \ rm -rf /cmake-build mkdir /build && \ cd /build && \ /src/qt/configure \ -prefix /usr \ -opensource \ -confirm-license \ -release \ -ccache \ -xcb \ -opengl \ -skip qt3d \ -skip qtcharts \ -skip qtdatavis3d \ -skip qtgamepad \ -skip qtgraphs \ -skip qtmqtt \ -skip qtopenapi \ -skip qtquick3d \ -skip qtquick3dphysics \ -skip qtquickeffectmaker \ -skip qtremoteobjects \ -skip qtsensors \ -skip qtserialbus \ -skip qtserialport \ -skip qtspeech \ -skip qtwebchannel \ -skip qtwebengine \ -skip qtwebsockets \ -nomake examples \ -nomake tests

@SimonSchroeder The question is why the change in behaviour: but qc18 is ok, qc20 cannot open the same FILE MACRO Your statements are true, but why does behaviour apparently differ from Creator 18 to 20?

@Nils-Sjoberg said in Constrain Clang-Tidy and Clazy to just one file: @SGaist With great pleasure, English is not my native language. Done :-)

Excellent ! Happy coding !

@Louis100 Hi, Check this post about accessing the bug report system.

@bogong said in Android API and SDK version for maximising population of users. Which to choose?: @SGaist AppStore for Android applications??? It was meant as the Google application store hence shortened to "App Store" which name is Google Play and not the same as Apple's own AppStore.

@Simmania said in What is best way to implement controls that render very fast?: So I now choosed for QQuickItem + QSGGeometryNode. Not to complicated and hopefully fast enough. Please post your results from this try here once you have it working. Just in case someone stumbles across this thread in the future.

@IgKh yes this is the bug, updating my system fixed it.

@JKSH the QT_QML_OUTPUT_DIRECTORY is setting is not covered in the video tutorial itself, it is only in the github repository, one of the recent rating comments does hint at this: [image: db4c45f8-b684-4068-a7bf-c1ff17440729.png] I think if one includes it in the CMake file then it is enough (though i didn't test it), no need to use QML Language Server. Also your identifier tip solved the other warning, thanks.

How are you processing things currently ? Using multiple threads ? Involving the GPU ? What kind of processing are you doing ?