General and Desktop

@SGaist Thanks! But I found that the problem might cause by Visual Studio's QT plugin. After I reboot the computer, some coding errors occured in my ui file and qrc file. After I re-opened these files with QT Creator and compile my application again in VS, this problem seems fixed. @Christian-Ehrlicher The platform is Win10, Qt5, VS2019.

I found that Qt 6.11 already addresses this with a new QAccessible::Switch role (commit 293032a) mapped to ATSPI_ROLE_SWITCH on Linux and UIA_ButtonControlTypeId on Windows, which is the proper long-term fix. For 6.10.x, a backport patch in getRole() in atspiadaptor.cpp seems like a reasonable workaround: if (interface->role() == QAccessible::Button && interface->state().checkable) return ATSPI_ROLE_TOGGLE_BUTTON; Would such a patch be acceptable for 6.10.x, or is the recommendation to upgrade to 6.11?

@JonB These two don't need to be consistent, right? [image: 1e7dfa90-7084-4e39-a651-bbbb0e2195f2.png]

@kaixoo said in Am I using `TreeView` right?: I am using QML's TreeView and it's only rendering children of the QAbstractItemModel, not elements further below. That's incorrect. QRangeModel might be of help to avoid having to write the boilerplate.

@SGaist Thank you ... this is exactly what I was looking for!

@gav451 For full building of Qt, I'm not sure that the Xcode generator is even supported. Maybe it is, but I personally build with the Ninja generator. I follow the Linux instructions on this page: https://wiki.qt.io/Building_Qt_6_from_Git. It is possible that there other ways. But then again, you don't really need to.

@IgKh said in [Ubuntu] How get screen available geometry?: Adding a Wayland compatibility note on the availableGeometry property of QScreen could be a great first contribution, if you are so inclined. This would only be the start of myriad necessary/suggested doc notes for Wayland. For example, as you yourself pointed out QWidget::move() is a no-op, showMaximized() may do nothing or whatever, and the compositor may or may not do things, and differently from other compositors.... If the Qt docs really intend to do anything about Wayland I would rather it were a large effort from the team covering everything than the occasional user note.

@Sprezzatura I had the same problem. I have 3 simultaneous Visual Studio 2022 instances and Firefox with a lot of processes and huge memory usage. Another way to solve this is to limit the number of processors used to compile the solution as it will use less memory due less parallel compilation : Tools > Options > Project and solutions > Compilation and execution > Max number of parallel compilations ---> set it to a lower value.

I found the problem Problem was that I think : I receive 65536 point but my widget width only 2000px and 32.768(33) point equal 1px, I lost the peak value there. That is my opinion and I solved. If you are think problem is different. I listen. Windows 11 Qt 6.9.x Qwt-6.3.0

Thanks, solution found, similar to what you are suggesting. I dug a bit further into Qt docs and found the entry for setPointsConfiguration, which takes data in the form of QHash<int, QHash<QXYSeries::PointConfiguration, QVariant>> So my new code for setting the colors looks like: QHash<int, QHash<QXYSeries::PointConfiguration, QVariant>> ptsConfig; QList<BrthPosnPlots>::iterator brthItr = m_brthPosns.begin(); MultiLineSeries *thisSrs = GetLineSeries(srs); QList<QPointF> srspts = thisSrs->points(); quint32 ctSrs = srspts.size(); if ((ctSrs < 1)) return; qsizetype bpos; for (brthItr = m_brthPosns.begin(); brthItr != m_brthPosns.end(); brthItr++) { if ((*brthItr).GetEEPos() > ctSrs) continue; if (((*brthItr).GetEIPos() > 1) && ((*brthItr).GetEEPos() > (*brthItr).GetEIPos() + 5)) { for (bpos = (*brthItr).GetEIPos(); bpos < (*brthItr).GetEEPos(); bpos++) { ptsConfig.insert_or_assign(bpos, conf); // thisSrs->setPointConfiguration(bpos, conf); } } } if (!ptsConfig.isEmpty()) { thisSrs->setPointsConfiguration(ptsConfig); } The speedup is truly amazing! From over 2 sec down to < 20 msec for this method. Thanks to all for feedback and tips.

I mean that: [image: b899662b-0573-4eba-8081-b7708a394c32.png] When using the Windows style, the OS overrides my design. As a result, the interface looks different from what I created in the designer—for example, buttons shrink and gain invisible margins that I cannot modify. I’ve tried changing properties in the designer, applying QSS, and using a proxy style, but nothing has any effect.

The font family substitutes are only queried if the requested family does not exist, which is unknown as long as the population step has not happened. So that mechanism cannot be used to avoid the cost of populating aliases unfortunately, although you should end up resolving the correct font with this substitution in place. If you really want to get rid of the extra cost, then you could store the result of applicationFontFamilies() somewhere central and query that instead of hardcoding the "DIN-Medium" name. But note that this is a one-time 215 ms cost. The aliases are cached in the database once they have been resolved.

@JonB said in Basic application crashes in QGuiApplication constructor if QCoreApplication::instance is called.: which we know should crash QGuiApplication app(argc, argv); qDebug() << qGuiApp->applicationDisplayName(); shouldn't crash.