General and Desktop

It's because your application is not hiDPI aware and windows does scaling by simply upscaling the bitmap that your application rendered in the window's back buffer before compositing.

@YamiTheWitch said in Error while compiling Qt6.9.0 on debian 12: building without another error? c++: fatal error: Killed signal terminated program cc1plus so it was killed because the machine ran out of memory

@Caeden, is your implementation available anywhere? It being in Python is valuable for me. BTW, for anyone else who sees this in the future, there is also stackoverflow.com/q/53127561.

Cool!.. thanks for answering..

Hi, Can you provide a minimal project that shows that issue ? Which version of Qt are you using ?

Hello, thank you for your help. I have already installed the latest version and tried several other things and still nothing has helped me. maybe the problem is really due to the error https://bugreports.qt.io/browse/QTBUG-63789. Currently only deactivating 'C++ exception' has helped me.

I haven't done it, but it seems possible to set application icons on Linux, too....if you know the desktop environment beforehand. For full reference, please see https://doc.qt.io/qt-6/appicon.html

last minute . I found the right way. In fact it is the -ffast-math compiler option which beheave differently on Mac and Linux with Qt 6.9.0 Qt 6.9.0 does not support any more very fast compiler optiion on Mac Mx CFLAGS = -pipe -Ofast $(EXPORT_ARCH_ARGS) -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=15.0 -Wall -Wextra $(DEFINES) CXXFLAGS = -pipe -stdlib=libc++ -std=c++17 -Ofast -funroll-loops -flto -march=native -DNDEBUG -Ofast -std=gnu++1z $(EXPORT_ARCH_ARGS) -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=15.0 -Wall -Wextra $(DEFINES) Fast optimisation does not work any more on 6.9.0. Is it Qt or Apple difficult to say. Thank you anyway .

Ugh I did forget, so sorry, my bad... Qt Creator 14.0.2 Based on Qt 6.7.3 (GCC 10.3.1 20210422 (Red Hat 10.3.1-1), x86_64) Built on Sep 27 2024 00:13:58 From revision 3004ebc0af Anyway, Finally Narrowed it all the way down to: Menu Bar-> Edit[menu]-> Preferences[submenu]-> C++[left-hand category list item]-> Clangd[tab item]-> Background Indexing[combo box, third setting in the list]-> <<Any setting other than "off">> - yes I checked them all and only "off" solves it Workaround: **Changing the combo box from its current setting to "off" solves the issue. ** Again, what appears to be happening is clang updates the progress bar in the status area below -> and when it seems to be finished, the designer area (the main form and widgets editor/preview area) is refocused. It's just a guess but maybe there is a slot setting the designer focus back to after the indexing is invoked, completed, or otherwise signaled in the background. This workaround seems to work for me for now, so I'd say it's solved along with the issue that was filed. Thanks. I hope this helps out people that run into this issue in the future.

@RobertSommer My answer is for when you use Q_ENUM() for your enum, which I thought was what you were doing. The code you show has no Q_ENUM(). If you expect something about being able to convert a plain C++ enum with no Q_ENUM() then it has nothing to do with Qt. For that you can search c++ enum to string to discover (C++ does not offer it natively). Other than that I don't know about your compiler error. Did you try the single statement code I quoted? Note how the comment there did say: // MyEnum needs to be declared with Q_ENUM macro

@casina When your QOpcUaClient emits endpointsRequestFinished you can do following in the slot to change the endpoint. void UaClient::endpointsRequestFinished( QList<QOpcUaEndpointDescription> endpoints, QOpcUa::UaStatusCode statusCode, QUrl requestUrl) { for (QOpcUaEndpointDescription& epd : endpoints) { // Connect to unsecure node if (epd.securityMode() == QOpcUaEndpointDescription::MessageSecurityMode::None && epd.securityPolicy().contains("None")) { m_client->connectToEndpoint(epd); } } Maybe your opcua server does not allow a connection to the unsecured endpoint as you try to do. With the above mentioned approach you can select a different endpoint. To me it looks like during building the opcua module cmake was not able to find openssl on your pc. This is required to be able to use secure endpoints. All secure endpoints from your server are annotated with "not supported". https://doc.qt.io/qt-6/qtopcua-build-openssl.html

@RobertSommer If you want a model to copy, Python's RotatingFileHandler and more specifically TimedRotatingFileHandler seem to provide what you are speaking about. As you can see it requires a library and a bunch of code to implement, you could write similar using C++ and some Qt calls.

Please see my post on stack overflow and provide a reasonable explanation. I believe this will help in a unsavory way. https://stackoverflow.com/a/79607899/13585636 Respectfully, Joe F.

Hi I didn't have that particular issue but had one related to WA_TranslucentBackground recently : so it has to be cumulated with FrameLessWindowHint, and for my case I also need the permenent stay on top property. If I add the stay on top hint to translucent and frameless, the window becomes fully opaque. If you need opaque components on a transparent window (which is what I was looking for), you might be screwed. Otherwise, you might want to try QWidget::windowOpacity, which is simplier to handle and doesn't suffer flags incompatibilities. I haven't tested it on QtWidgets, but in a QtQuick Window it works without flags (and on top of that a frameless window is more problematic in my case). There seems to be some incompatibility among window flags and attributes, at least for windows but I didn't find any doc from windows about that. I didn't insist.

@SimonSchroeder Well, I mean you can use a QPixmap to code each pixel individually to display an image, but why do that when you can just use .png :D

@Axel-Spoerl said in Invoking a slot from a non-Qt thread: I'd probably go for an interface class, living inside the std::thread, inheriting from QObject and running its own QEventLoop. From what I understand only the calling thread does not have anything Qt-based. In order to emit a signals there is no need to start an event loop inside that non-Qt thread. Only a receiving slot would require an event loop. Or am I wrong about this? The quickest way would certainly be using invokeMethod. However, if you can (and are willing to) using signals is always better. If you don't want to introduce any Qt into that thread (yet) you can have a regular C++ function inside some existing Qt code and call that. This function can either use invokeMethod or even emit a signal for your. If it is inevitable to keep Qt out of your thread (in the long run) it makes sense to create something derived from QObject to be used inside your non-Qt thread. Then you can emit a signal using this object. I don't think you need anything special in the calling thread. emit is just a Qt keyword that gets removed by the preprocessor. From the compiler's point of view emitting a signal is just calling a regular member function. (The member function for the signal is generated by moc.) You need to be careful about object lifetimes. The calling object needs to live long enough for the slot to be executed. If the calling or receiving object in a connect statement is deleted, all queued slot invocations are also removed. Also, as your non-Qt thread does not have an event loop you cannot use deleteLater() to delete the object. If you cannot guarantee that your non-Qt thread runs long enough for the slot to be executed (or rather at least started) inside the Qt thread (and thus cannot guarantee a long lifetime for the QObject-derived object) using invokeMethod is the safest way. Maybe it even makes the most sense to use invokeMethod if you don't rely on member variables of the calling object, but instead hand over all data necessary for the slot as function arguments. It certainly avoid thinking about object lifetimes (and thread lifetimes).