Qt 6

@AnneRanch
#1 - this is normal on Linux and has to do with security (you usually really don't want downloaded files to be executable out of the box). A software developer should know how to make a file executable.
#2 - QtCreator is installed by default when using the online installer provided by Qt Company
#3 - It is an installer downloading most data from the Internet (including QtCreator). If you want an installer which includes everything then use offline installer (but keep in mind - it is big).

An error occurred.But other pc Start Over!
Windows10 VisualStudio2019 x64 Qt6.0.0

(mega 2.62GB)
https://mega.nz/file/tqQ0RJBT#HGZRV0B_k9Ekrf952vJ2-we6LK2nnfUCftSHmoO2syg

command(admin)
c:\qt6\src>cmake --install c:\qt6\src

@JKSH - I found this:

gtkThemes.png

But it isn't working. And I see no way to turn it on. Everything I create with Qt on Linux comes away with the standard "Qt theme".

gtkTheme-01.png

On the left, we have Qt. On the right, Code::Blocks. I'm not making a comparison here, because I know Code::Blocks uses wxWidgets, and they adapt instantly to any theme. But I am trying to point out that I just created both of these on my Linux box. C::B holds true to my theme while Qt doesn't. I'm just trying to make Qt roll with my theme. And I know it can, because I use some Qt software on Linux that uses any theme I set. I just don't know how to get my Qt stuff to behave in kind. Any help in this matter would be greatly appreciated.

@ronron
Could you try the link www.qt.io/download-qt-installer for the online installer? That would automatically detect your operating system. In your case, Windows 10 platform. It could help to see that you are downloading the right version, 64-bits.

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:
Screenshot from 2020-12-21 09-30-19.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.