General and Desktop

Hi, Using multiple views on top of the same model is one of the core feature of the model view paradigm. You have one single source of data and present it through different (or similar) means to the user.

It is a problem with the installer's binaries they were build on Ubunto with a different libc or libstdc++ library than on Raspberry. https://bugreports.qt.io/browse/QTBUG-137145 You can build it from the sources, then it works. Install required packages sudo apt install cmake libfontconfig1-dev libdbus-1-dev libfreetype6-dev libicu-dev libinput-dev libxkbcommon-dev libsqlite3-dev libssl-dev libpng-dev libjpeg-dev libglib2.0-dev libgles2-mesa-dev libgbm-dev libdrm-dev libvulkan-dev vulkan-tools Install wayland libs sudo apt install libwayland-dev libwayland-egl1-mesa libwayland-server0 Download and extract https://download.qt.io/official_releases/qt/6.8/6.8.3/submodules/qtbase-everywhere-src-6.8.3.tar.xz, tar -xf qtbase-everywhere-src-6.8.3.tar.xz Switch to the directory where the file is extracted, make a directory for the build inside, switch into the build directory cd /path/to/qtbase-extract, mkdir ./build, cd ./build Build cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/raspifm/Qt/6.8.3-aarch64 -DQT_FEATURE_opengles2=ON -DQT_FEATURE_opengles3=ON -DQT_FEATURE_kms=ON -DQT_AVOID_CMAKE_ARCHIVING_API=ON .. cmake --build . --parallel 4 Install cmake --install . Build modules, e.g.: qtsvg, qtimageformats, qtwayland Download and extract https://download.qt.io/official_releases/qt/6.8/6.8.3/submodules/qt....tar.xz tar -xf qt....tar.xz Switch to the directory where the file is extracted, make a directory for the build inside, switch into the build directory cd /path/to/qt...-extract, mkdir ./build, cd ./build Build /home/raspifm/Qt/6.8.3-aarch64/bin/qt-configure-module .., then cmake --build . --parallel 4 Install cmake --install .

That solved it. I'm not sure what happened, but something got messed up my build dir.

@JonB, that's what I was looking for! Thanks.

Hi and welcome to devnet, Does it happen with only a single file or are they all affected ? It there somewhere a sample file that could be used to test this issue ? Which OS are you running your application on ?

That's how I understood the code.

@rcx11 it uses a similar approach to gRPC/QtRemoteObjects in that the files that are compiled are generated using calls to the generators via cmake. I checked Qt6.10.0 on windows 11 and indeed, until you configure the file cannot be found: The file that generated (for reference of others reading this thread): [image: 8bfbacc8-18a1-419d-9f48-7757554d7203.png] I'd recommend marking as resolved with @Paul-Colby 's response.

Hello, is there any update for this issue? I'm also facing the problem that the QEnums properties are not loaded by QtDesigner

It works fine for me with Qt6.9.1 with the windows11 style: int main(int argc, char *argv[]) { QApplication app(argc, argv); QTableWidget tw; tw.setRowCount(5); tw.setColumnCount(1); auto item = new QTableWidgetItem("Item"); tw.setItem(0, 0, item); QTimer::singleShot(2000, &tw, [&]() { tw.item(0, 0)->setCheckState(Qt::Checked); }); tw.show(); return app.exec(); } Please provide a minimal, compilable example of your problem.

@SuhasKrishanamurthy hi, Since you marked your thread as solved, can you share what you did / change to fix the situation ? It might help other people.

@SGaist Thanks for your help. I already have access to QtWebKit. Its there in my Qt installation. Crash is intermittent so inferring what content triggers crash might not be easy. I am trying to figure out again if I can instead use QWebEngine. Lets see, hopefully I wont have to use QtWebKit.

hi @aha_1980 Thanks for the reply. Before I got it, I'd just started doing a thing where I was counting the bytes read back in and only starting to take any notice of the data when I had read in the number of bytes sent out, so I was along the right lines. It's a bit of a pain, but with what you're saying about bytesReceived being called not being a guarantee it's gone out on the line, I guess it's not going to help anyway. For a while I have been thinking I need to get to grips with QSerialPort but as I know qextserialport so well I've been lazy. I do know that in v6 qext... is no longer available. Thanks for the post.

@AndyBrice said in Cache locality and QString: Ok, thanks for the feedback. It looks like there is no straightforward ways to improve performance, while keeping the flexibility I need. Correct. The optimization will come at a cost of working only when on a predictable subset of real world data. Because you've stated that you need a generalizaed solution, the optmization tricks wont work reliably. If you can assign hard limitations to your dataset...THEN you can consider what kinds of optimiztions make sense.

@yonizaf You should not create a new ticket. You commented in the existing, let's see whether this triggers any actions :-)

Code: #include <QCoreApplication> #include <QLocale> #include <QDate> #include <QtDebug> int main(int argc, char* argv[]) { QCoreApplication a(argc, argv); QLocale locale1(QLocale::German, QLocale::Germany); for (int m = 1; m <= 3; m++) { QDate date1(2025, m, 1); qDebug() << "locale1=" << locale1 << " date1=" << date1 << "locale1.toString( date1, \"MMMM\" )=" << locale1.toString(date1, "MMMM"); } const auto locales = QLocale::matchingLocales(QLocale::AnyLanguage, QLocale::AnyScript, QLocale::AnyCountry); for (const QLocale& locale2 : locales) { if (locale2.country() == QLocale::Germany && locale2.language() == QLocale::German) { qDebug() << "locale1 == locale2 =" << ( locale1 == locale2 ); for (int m = 1; m <= 3; m++) { QDate date2(2025, m, 1); qDebug() << "locale2=" << locale2 << " date2=" << date2 << "locale2.toString( date2, \"MMMM\" )=" << locale2.toString(date2, "MMMM"); } } } return 0; } Results: Qt 5.15.18/MSVC2019/Windows: Qt 5.15.18/XCode/macOS: locale1= QLocale(German, Latin, Germany) date1= QDate("2025-01-01") locale1.toString( date1, "MMMM" )= "Januar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-02-01") locale1.toString( date1, "MMMM" )= "Februar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-03-01") locale1.toString( date1, "MMMM" )= "März" locale1 == locale2 = true locale2= QLocale(German, Latin, Germany) date2= QDate("2025-01-01") locale2.toString( date2, "MMMM" )= "January" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-02-01") locale2.toString( date2, "MMMM" )= "February" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-03-01") locale2.toString( date2, "MMMM" )= "March" ^^^Month is incorrect for locale2^^^ Qt 6.7.3/MSVC2019/Windows: Qt 6.7.3/XCode/macOS: locale1= QLocale(German, Latin, Germany) date1= QDate("2025-01-01") locale1.toString( date1, "MMMM" )= "Januar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-02-01") locale1.toString( date1, "MMMM" )= "Februar" locale1= QLocale(German, Latin, Germany) date1= QDate("2025-03-01") locale1.toString( date1, "MMMM" )= "März" locale1 == locale2 = true locale2= QLocale(German, Latin, Germany) date2= QDate("2025-01-01") locale2.toString( date2, "MMMM" )= "Januar" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-02-01") locale2.toString( date2, "MMMM" )= "Februar" locale2= QLocale(German, Latin, Germany) date2= QDate("2025-03-01") locale2.toString( date2, "MMMM" )= "März" ^^^ Month is as expected^^^ So the localised month is wrong (but only inside the loop) for Qt 5.15.18. Weirdly, day of week ("ddd" or "dddd") is correct in both cases. I can work around it, but it is a very odd bug.

@Taytoo https://forum.qt.io/topic/136174/printing-a-simple-pdf

Hi -- thank you for the thought, sorry about the delay. I'm honestly not sure how that relates? I've tried to use defaults to see if I can find cached versions of the Preferences, but I haven't seen anything other than the usual -- for the user of an app, their preferences for that app are stored in ~/Library/Preferences/<AppID>.plist, and there are cached "binaries" in ~/Library/Caches/<Company>/<AppName>/qmlcache (qmlc files, which according to some docs suggests its for live state?). As the preferences I'm restoring are from [Q]Settings in a QML file, do you think they could be coming from a qmlc[ache] from a previous run? Asked another way, would QML look there in the absence of an OS-supplied preferences (which would have to behave similarly in e.g. Windows/Registry editing). FWIW there are a very large number of qmlc files in ~/Library/.../qmlcache. Cheers!

Qt 5.6 is even more outdated than Qt 5.15. Please try a newer version of Qt!