General and Desktop

I'm against. Id rather see the qt docs pages go back to the way they looked when trolltek was still a thing: you know, higher contrast, less window dressing.

@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)

thanks for reply, but QScreen::grabWindow is unacceptable, because of resolution. In my case window is often has less resolution than pixmap I'm rendering to. Resulting pixmap must be of original resolution, FulllHD, 4k or more.

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.

@GrecKo "Oh, I did that, but it's a bad solution and mostly a crutch, as I know that all display servers on all platforms offer mouse capture functionality at the windowing system level, and that's exactly what should be used. The problem with setPos is that it's an attempt to modify a system component – a direct security violation – and new window managers like Wayland directly forbid such a function. I've written about this here and here, but I haven't found a relatively simple solution to this problem. Currently, I'm using the outdated xWayland for Wayland to redirect setPos through the X11 API where such functionality is allowed. However, using xWayland for games means huge FPS losses for no good reason, which is especially noticeable with Vulkan, and that's extremely frustrating. I need a way to directly subscribe to the cursor capture functionality, so that for a specific window, the display server starts sending deltas instead of absolute coordinates. These deltas should always be received, regardless of where the cursor physically lands."

@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.