Qt 6

Ah great to see that its planed for 6.2 Thanks guys

@zhangyiant Thank you very much, I had such a problem too, it worked for me too.

thanks for trying to shed some light on this. As I said, I have already installed the vulkan SDK (the "official" one from LunarG as I am trying to build for windows). I have even added the include directory directly in the *.pro file, and have observed that when opening the qt3d project with QtCreator, it can correctly resolve the vulkan libraries, so I think this is not the problem. I will try your suggestion of putting the vulkan headers directly in the qt directory and see if that gets me anywhere..

Can you maybe attach C:\Qt\Tools\QtCreator\share\qtcreator\QtProject\qtcreator\profiles.xml? This is the place where all auto-detected kits are stored...

FYI the problem was resolved after manually compiling up the imageformats package + adding it to the build dir. For future references: please make sure that if you try to load an image file that is currently not supported, then provide some sort of feedback to the user (developer)!

@JonB I have done this but now When I emit a signal sendmessage() from mainwindow class (sendmessage() signal is working perfectly fine) to the slot of thread class so the thread class does not emit the gotnewmessage() signal when I want to send the data to mainwindow class that it needs to show in text box. Do you hav any idea why is that happening?

@SGaist Thank you very much, that saved me a lot of disk space!

also, I should note that lldb works just fine, not showing source code was simply me running the program from an incorrect path. I guess lldb is the way to go until you guys release a fully operational kit for ARM...

@noone said in QtFuture not found: workaround ? #include <QFuture>

@Christian-Ehrlicher True and this is what I did. It works: void MainWindow::removeItem(const QString &text) { for (int i = 0; i < ui->listWidget->count(); ++i) { auto item = ui->listWidget->item(i); auto itemWidget = dynamic_cast<CustomWidget*>(ui->listWidget->itemWidget(item)); if (itemWidget->getText() == text){ delete item; break; } } }

@SGaist Ya I was looking at this -> https://stackoverflow.com/questions/50083278/in-qt-how-to-remove-child-widget-from-parent-after-receiving-the-signal-generat. I think this is what I have to do.

It is very hard for an individual (or a group) to debug your whole program (its design and its implementation) via a forum. This is not likely to succeed, in my opinion. To have success in a Q&A forum, the problem statement needs to be minimized. In your case, @fari35 , I would highly recommend that you start by only compiling and running the exact "untouched" sample code first: https://github.com/qt/qtbase/tree/fc9cda5f08ac848e88f63dd4a07c08b2fbc6bf17/examples/network/threadedfortuneserver Also compiling and run the exact unedited official client sample: https://github.com/qt/qtbase/tree/fc9cda5f08ac848e88f63dd4a07c08b2fbc6bf17/examples/network/fortuneclient Make sure all of that works first. I was able to compile and launch both of those with no issue, and this is what I see: [image: 58d7f66a-68fd-4f78-b620-e86c731e70b8.png] Once you do that, then start tracking your changes using git, and make one tiny change a time (in order to work slowly towards whatever your goal or assignment is). When you make one tiny change (as small as editing or adding just one line of code) and the change fails to do what you expect, then you can use the time-tested bug-reporting technique of: State what you did (the single tiny change). State what you expected. State what actually happened.

@fari35 You make a MainWindow object/instance by MainWindow instance or MainWindow *istance = new MainWindow. when I'm trying to create an object of MainWindow class in server.h class You absolutely do not want to create, or reference, any MainWindow class/object, or for that matter any UI object, in your server.h/.cpp files, which should solely work on QTcp... stuff! And nor should it attempt to #include "mainwindow.h".... You need to learn to keep your classes separate, each one only doing what it needs for its own specialized functionality. If, say, you do have a QMainWindow in an application using QTcpServer, mainwindow can know about server, but not the other way round. MainWindow can call methods in QTcpServer, but not the other way round. Or, they can use signals/slots if required to communicate.

Thank you

TreeView is now available although it's odd that it isn't included in Qt out of the box.

Looks like a bug. I have reported it at https://bugreports.qt.io/browse/QTBUG-89436

Looks like you may have an issue with your module build. I do not have Big Sure yet but I just tested on Catalina with a build of the latest dev checkout of the module and except an issue with the install folder quickly fixed I was able to build a small project based on your CMakeLists.txt file.