General and Desktop

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

@Saviz dataChanged() signal is the primary reason your GUI knows data has been changed within your model and updates it accordingly.

@aiyolo Merge both transformation (scaling by factor 3 and translation to 5/5) and apply the resulting transformation to your item/point.

@SGaist @Pl45m4 Excellent thanks guys. Now to read up on hash tables.

@RobertSommer said in Socket notifiers cannot send from another thread: Can a signal be set by an inherited receive function, event? Set?! You can emit a signal wherever you can also call a function. But depends on your logic if that makes sense.

@SGaist The header file with all its content: #pragma once #include <QStringList> inline const QStringList paths = { "..." }; inline const QStringList registryKeys = { "..." }; I know that the window is fixed in size, it is my temporal solution to this lag problem.

@Pl45m4 said in Connect , SendMessage, Emit - When should I take what?: @RobertSommer You connect Ink to Controller and Laser the same way. I assume these are printers (or printer software)?! Ink Jet + Laser printers, right?! That is correct.

@Axel-Spoerl said in Timer configuration, the possibilities: Something like that? OK, thanks for the sample.

Were you able to figure this out?

Thanks for the support. Question answered, connection is made via connect. [image: 015b582f-cd3a-4da0-9740-97292664fb94.png]

@IgKh said in Implementing "dark mode" on Ubuntu 24.04 (ok) vs Fedora 42 (not ok): Hi @Christophe-R and welcome to the forum. If the QEvent::ThemeChange is correctly delivered to your top level window, I think that the Qt style in use in your Fedora installation might not have a dark palette (style hints are only hints after all - the actual style class must respect them). Try running your application with the -style Fusion command line parameter - the Fusion style is shipped with Qt and is known to support dark color scheme hint. I am using in my C++ code: app.setStyle("fusion"); Check if the QT_QPA_PLATFORMTHEME environment variable happens to be set - especially with the value qt6ct or qt5ct. qt6ct is a great tool for getting Qt apps to blend in with GTK based desktop environments, but it it messes with palettes pretty heavily to achieve that. QT_QPA_PLATFORMTHEME is not set

Well, David, we've all been there, have we not? The focus theft topic caused me a slight panic wave: I re-factored the focus chain handling in widgets a while ago. What looked like piece of beauty, introduced some awful regressions. And since you've caught me red handed on a dock widget regression earlier, I smelled trouble coming my way ;-)

Sorry for all the inconvinience, I will try to express more exactly to avoid this kind of misunderstanding

@Christian-Ehrlicher yep that was it. Can't believe I missed that for so long thank you both for the help

@JKSH Thank you for explanation!