General and Desktop

They are separate issues, but no. I dont think external links within the qt docs is a good idea, for some of the reasons stated in the JIRA ticket. I'd also be happier to see an easier process to download and locally host the API documentation. (I'm all about minimizing dependence on the web/cloud) When I've tried to build and host locally I always ended with many broken links, but haven't tried since around 5.3

@Dariusz said in Startup 6.9.1 A LOT Slower than 6.8.1: my apps starts A LOT slower, I'm talking about 60-80 second start up in debug mode comparing to 5-15 That sounds very abnormal. I haven't seen anything like this myself, but if you can simplify your project into a reproducer, please create a bug report at https://bugreports.qt.io/secure/Dashboard.jspa, attach your reproducer, and add [Reg 6.8.1 -> 6.9.1] to your report title to highlight that it is a recent regression.

@JKSH said in Is there a more efficient way to decoding JSON from QWebSocket?: No. UTF-8 text should not be treated as an array of bytes! I never suggested to do Unicode text processing using a QByteArray. An UTF-8 encoded string is quite literally an array of bytes, and I think there is no better suited Qt container for storing those at the moment. It is perfectly fine and safe to pass UTF-8 encoded strings between APIs in QByteArrays. Even the return type of QString::toUtf8() suggests that QByteArray is currently the Qt's type of choice to store UTF-8 strings. So I'm little hard-pressed to accept that reading and writing UTF-8 text using QByteArray on a QWebSocket would be somehow bad API and had to be avoided, while at the same time using QByteArray seems totally fine for passing UTF-8 strings in many other parts of Qt. I'm not even sure what added value over QByteArray does QUtf8String provide? Except maybe some sort of type tagging - way of saying that this not just any byte array, but an utf-8 encoded char array. Any kind of UTF-8 string processing (except trivials like concatenation) requires decoding into some evenly sized char type array anyway. But that debate is off-topic.

The original post asked how to generate a working UI at runtime from a specification for the UI written in XML. This is common in many commercial and open-source simulation platforms including those used primarily for games. Not easy in 1997.. Maybe easier today, in 2025. search for "Immediate Mode GUI library" TLDR: An early example of such a UI is present in the open-source Flight Simulator, FlightGear. It is entirely driven in runtime by XML, and includes the usual UI elements Menus, Keymaps, Dialogs and the usual suspects for dialog widgets. Flightgear was started in 1997. So the idea of an XML-driven menu system was quite new. Flightgear at that time used PLIB for its UI. In its next branch, it will be converting away from PLIB to a separate internal GUI library. The FlightGear's source code is hosted on GitLab. The current implementation does not use QT for the in-simulation UI. The UI seen once the simulator is running is generated on the fly. Many menu items and dialogs are specific to particular aircraft and their corresponding cockpit components and are supplied as part of an aircraft specification. Aircraft are developed and maintained separately from the Simulation program. See flightgear.org for more information.

Dear mrdebug, Thanks for your valuable answer. There was one thinking like me. Regards, Mucip:)

@DanMQt As @Pl45m4 has written. Furthermore I have never seen a Windows or Linux app which has a tooltip when hovering the window title, so I don't know why you would think this is standard. Up to you whether you want to do the extra work to achieve it.

@byrAlpha Hi, You can try this. https://stackoverflow.com/questions/68769475/how-to-set-the-color-of-caret-blinking-cursor-in-qlineedit

@JonB THAKN YOU! You save me !

I have gotten a new sample from the library vendor, and it does use paintGL. We were working off a sample from 12 years ago as our base and apparently they have updated a lot since then. I am trying to fit their new implementation in and see how it works. Thanks for the feedback

@AliQT FWIW I included a CMakeLists.txt which should work (again, inside it a couple of lines for ActiveX need uncommenting) as an alternative to .pro/qmake. Most people use cmake with Qt6, but .pro/qmake is still supported if you prefer. Just check the other code does not require Qt5, else you won't be able to use the Q_MOC_INCLUDE() it now relies on.

Thank you for the tip; I'm using Python, so I rewrote like this, and it works: class VerticalScrollArea(QtWidgets.QScrollArea): def __init__(self): super().__init__() self.setWidgetResizable(True) self.setHorizontalScrollBarPolicy(Qt.ScrollBarAlwaysOff) self.setVerticalScrollBarPolicy(Qt.ScrollBarAsNeeded) def eventFilter(self, object, event): # This works because QScrollArea::setWidget installs an eventFilter on the widget if object is not None and object == self and event.type() == QEvent.Resize: self.setMinimumWidth(self.minimumSizeHint().width() + self.verticalScrollBar.width()) return super().eventFilter(object, event)

Hi @Ben-Campbell-Wallis, sorry for the delayed response. If you use vcpkg protobuf installation please make sure that the vcpkg tripplet binary directory is in PATH when you build your project. I expect that it should be something like "C:/Projects/_clientserverpoc/smappoc-gl-client-grpc/build/Desktop_Qt_6_9_1_MSVC2022_64bit-FromSrc-Debug/vcpkg_installed/x64-windows/bin" in your layout. It should help, but we probably need to think about setting it automatically. Qt delivers packages where protoc plugins are build statically, so you don't face missing dependency issues.

for (int i = 0; i < count(); ++i) { QWidget *viewport = widget(i)->parentWidget();//viewport qDebug() << viewport->metaObject()->className(); QScrollArea *scrollArea = qobject_cast<QScrollArea*>(viewport->parentWidget()); qDebug() << scrollArea->metaObject()->className(); Q_CHECK_PTR (scrollArea); scrollArea->setVerticalScrollBarPolicy(Qt::ScrollBarPolicy::ScrollBarAlwaysOff); scrollArea->setHorizontalScrollBarPolicy(Qt::ScrollBarPolicy::ScrollBarAlwaysOff); }

This is for sure no compiler issue. More an access problem due to a virus scanner or tests running simultaneously.

@JonB Oh, right. I just did and it worked. I was tried to change CalibrationMaterial::updateTextures(QRhi *rhi, QRhiResourceUpdateBatch *resourceUpdates) to void CalibrationMaterial::updateTextures(QRhi &rhi, QRhiResourceUpdateBatch *resourceUpdates) so many other issues occured and I tried to fix them. But wit just *rhi, it solved.

It seems like some .dll files was missing. I ran the debug log and it said the libwinpthread-1.dll was missing. So I copied it to the mingw64/bin/ folder and then it worked. It didn't say missing that .dll file when I run it normally but only when run by debug log

@nicker-player said in when using the qml occured the errors.couldnt find the wrong code line.: so how to find the wrong place.any good ideas? Do you use QPainter somewhere? You seem to make screen-shots - I would start there. You can also remove functionality step by step until it does not crash anymore then you know where it happens. Also, debugger is the usual tool to investigate problems...

Well, this would be a possible workaround, but it neither explains nor solves the underlying problem …