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

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

That depends on what you specify for your UX. If you don't want to have to use a submit button then mapping each textfield to a c++ property is the more direct way yes. Doing that on editingFinished is a good solution.

@jsulm Nice, thank you, I tried to build the MSVC2022 project in QtCreaator, this problem has been bothering me, and now it has finally been solved, the same project Visual Studio can run, I want to switch the IDE, hahahahaha

@Christian-Ehrlicher Okay, I finally saw the issue. In my code std::this_thread::sleep_for(std::chrono::milliseconds(100)); was outside the pool.enqueue() function. So the main thread was constantly sleeping and couldn't process the signals.

Hi, good advice of @Christian-Ehrlicher 's to skip it, otherwise there is a solution here: https://bugreports.qt.io/browse/QTBUG-122589

@Redman Yeah, I've seen this option. Thank you very much for your help, I will keep an eye on updates, and as soon as there is a way to make everything working in Qt, I will write in this thread and mark it as solved.

Are you sure? This seems pretty nonprofessional. I have no better explanation, though. I would assume, that this affects every fullscreen app... I write a media player, for example. They recently implemented this: https://www.qt.io/blog/expanded-client-areas-and-safe-areas-in-qt-6.9 Which seems to me quite similar. Yes, as a workaround, i use the height of the hidden status bar... Producing wasted space on old phones without rounded corners.

@hskoglund Yes I think that is right, but then I just don't know which library are essential in the creation of the static build for wayland. openat(AT_FDCWD, "/home/username/.conan2/p/b/qt9e43eba220521/p/plugins/platforms/glibc-hwcaps/x86-64-v4/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/username/.conan2/p/b/qt9e43eba220521/p/plugins/platforms/glibc-hwcaps/x86-64-v3/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/username/.conan2/p/b/qt9e43eba220521/p/plugins/platforms/glibc-hwcaps/x86-64-v2/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/username/.conan2/p/b/qt9e43eba220521/p/plugins/platforms/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/username/.conan2/p/b/qt9e43eba220521/p/plugins/sqldrivers/glibc-hwcaps/x86-64-v4/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/username/.conan2/p/b/qt9e43eba220521/p/plugins/sqldrivers/glibc-hwcaps/x86-64-v3/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) There are two more lines of sqldrivers missing This is the rest of the output, is there one of the libs that are critical?

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

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

Because I would have thought you want that flag for the default case Ah, thank you, but in this specific case I would have wanted another type of recursion to happen : ) Suggestions go to https://bugreports.qt.io/. Thank you, I will try to provide as much info as possible and post the link here when it's done.

Reported as https://bugreports.qt.io/browse/QTCREATORBUG-32859

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

Found it! This error was caused by the compiler option "/Zc:hiddenFriend-" !

This import does not import a file, but a directory, which is why the above error is always reported: no such directory I understand a little bit now. The use of qml is like the classes and objects of c++. What are defined in the qml file are types. When using them, they cannot be directly referenced by the type name (unless a singleton object is defined). Instead, an object instance should be created using the type defined in qml, and then this instance object should be referenced. For example: [image: 657e3e2e-02f6-4281-a2e6-b140b5aaa175.png] [image: 2b622949-0b55-46e7-82e9-4037d087037f.png] [image: 9f3149dd-971c-4580-a884-3aaa349f0e46.png]

Hi all, The issue is now resolved. The project I was porting required glibc 2.29, whereas RHEL 8.10 only supports up to glibc 2.28. When I installed Qt using the online installer, it was expecting 2.29, rather than the system provided version. I couldn't find any precompiled Qt libraries for my version of RHEL, so I rebuilt Qt from source using the system provided version of glibc, and now there is no crash. Thanks for the responses!

@JonB I managed to solve it, It was a problem with QSet, function ,,insert'' took a lot of time event though I used ,,reserve''. I didn't have this problem in my console app because I used stl containers.

Glad you found a solution and thanks for sharing ! :-)

Thanks Christian, 32 bit build all working now. I skip webengine, webview, location as I don't need those.