I have a Qt GUI class preferencesWindow that, obviously, is responsible for handling the user preferences. I have some fields that manage the connection to a database server. When a field is left, dbsChanged() method is called. Below is some code I managed to write:
void preferencesWindow::dbsChanged() {
QFuture<QStringList> loader = run(this, &preferencesWindow::get_databases);
QStringList databases = loader.result();
if (databases.length()) {
this->ui.database->show();
this->ui.nodb_label->hide();
this->ui.database->clear();
this->ui.database->addItems(databases);
this->ui.okButton->setDisabled(false);
this->ui.validationStatus->setPixmap(QPixmap(":/icon/tick.png"));
} else {
this->ui.database->hide();
this->ui.nodb_label->show();
this->ui.okButton->setDisabled(true);
this->ui.validationStatus->setPixmap(QPixmap(":/icon/error.png"));
}
}
QStringList preferencesWindow::get_databases() {
QSqlDatabase test_connection;
if (QSqlDatabase::contains("PREFEREMCES_LIVE_TEST_CONNECTION"))
test_connection = QSqlDatabase::database("PREFEREMCES_LIVE_TEST_CONNECTION");
else test_connection = QSqlDatabase::addDatabase("QMYSQL", "PREFEREMCES_LIVE_TEST_CONNECTION");
test_connection.setHostName(this->ui.serverAddress->text());
test_connection.setUserName(this->ui.username->text());
test_connection.setPassword(this->ui.password->text());
test_connection.setDatabaseName(this->ui.database->currentText());
test_connection.setPort(this->ui.serverPort->value());
test_connection.open();
qDebug() << "Error: " << test_connection.lastError();
QSqlQuery show_databases = test_connection.exec("show databases");
QStringList databases;
while (show_databases.next()) {
databases.append(show_databases.value(0).toString());
}
QSqlDatabase::removeDatabase("PREFERENCES_LIVE_TEST_CONNECTION");
return databases;
}
Since get_databases can take a long time, I thought that putting in on a separate thread as you can see in these two lines:
QFuture<QStringList> loader = run(this, &preferencesWindow::get_databases);
QStringList databases = loader.result();
could solve the problem. It runs on a separate thread, but it still freezes the GUI (while working).
How should I rewrite this entire process? I though of some solutions, but I am not really sure about their performance, and I don't want to work uselessly...
It freezes the GUI because even though the get_databases call is in a separate thread, you still wait for the results which causes the freeze.
I don't know how to do it in Qt, but the normal thing would be to open a dialog saying "please wait" or something with a cancel button, and have the worker thread send a signal to the parent (GUI) thread when done.
The QFuture will wait until the thread sets the result when your call loader.result(). You have to wait for that value later.
I guess you could store the future object as member of preferencesWindow and send yourself a signal, when finishing get_databases. So you give your application time to process other events during this wait time.
You can use QFutureWatcher to monitor that status of the QFuture object, like written in the documentation:
// Instantiate the objects and connect to the finished signal.
MyClass myObject;
QFutureWatcher<int> watcher;
connect(&watcher, SIGNAL(finished()), &myObject, SLOT(handleFinished()));
// Start the computation.
QFuture<int> future = QtConcurrent::run(...);
watcher.setFuture(future);
Related
I have following classes:
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_TREELIST_ITEM_CHECKED(wxID_ANY, MyFrame::OnItemChecked)
EVT_TREELIST_ITEM_EXPANDED(wxID_ANY, MyFrame::OnItemExpand)
END_EVENT_TABLE()
class MyThread: public wxThread
{
public:
MyThread(MyFrame *frame, wxTreeListItem &item);
virtual void *Entry();
SeleSyncFrame *m_frame;
wxTreeListItem item;
};
class MyFrame
{
friend class MyThread;
private:
wxTreeListCtrl* m_treelist;
public:
void OnItemExpand(wxTreeListEvent& event);
};
I have to update m_treelist on every EVT_TREELIST_ITEM_EXPANDED event. For that I am calling OnItemExpand().
void MyFrame::OnItemExpand(wxTreeListEvent& event)
{
wxTreeListItem item = event.GetItem();
MyThread *thread = new MyThread(this, item);
if (thread->Create() != wxTHREAD_NO_ERROR)
{
dbg.Error(__FUNCTION__, "Can't create thread!");
}
thread->Run();
}
constructor of MyThread class:
MyThread::MyThread(MyFrame *frame, wxTreeListItem &item) : wxThread()
{
m_frame = frame;
this->item = item;
}
Entry function of MyThread:
wxThread::ExitCode MyThread::Entry()
{
wxTreeListItem root = m_frame->m_treelist->GetRootItem();
m_frame->m_treelist->CheckItem(root, wxCHK_CHECKED);
//This back-end fun is time consuming
Calltobackend(string resp);
// I have to convert this string resp into xml and append all items of xml as children for 'item'.
(m_frame->m_treelist)->AppendItem(item, "child");
m_frame->m_treelist->CheckItem(item, wxCHK_CHECKED);
m_frame->m_treelist->UpdateItemParentStateRecursively(m_frame->m_treelist->GetFirstChild(item));
return NULL;
}
I want to create thread for every browse request and update corresponding item with its children. Is my approach is not correct? How should I achieve this? I was thinking of one more approach where I will use thread only to send request to backend and I will send response to Main thread using OnWorkerEvent. But I have to update item which is expanded with response returned by backend. How will that OnWorkerEvent will know which item from tree it has to update with children returned by response?
As VZ said, updating GUI from a different thread is a can of worms. Don't do it.
For your issue. Let's say you have to update a control (in your case, items of a treelist) with values that come from a long task.
The idea is simple:
On your user event handler (like OnItemExpand) just create and run
the thread. Don't wait for it, make it "detached".
In the thread code, just before it ends, post a message to the main thread by wxQueueEvent(). The value you need may be part of this message. Or
you can also write an accesible var, better using wxMutex; and use
the message to inform the main thread that that var is updated.
Write a new function (e.g. a MyFrame::OnMyThreadEnds) than handles the message and/or var. Here is where you update the GUI.
See http://docs.wxwidgets.org/trunk/classwx_thread.html
You can only use GUI objects from one (usually main) thread of your application, so your approach simply can't work. It's also not clear at all why would you go to the trouble of creating a thread just for doing this, it's not like there are any time-consuming operations being done in the thread here.
The standard way to use threads in GUI applications is to perform any long-running tasks in background worker threads and post events to the main thread to perform the GUI updates. You should structure your application like this unless you have really good reasons not to do it.
In more details, the traditional way to do it is for the worker thread to post wxThreadEvents to the main thread, containing the information that the main thread needs to perform the action. Notice that wxThreadEvent has SetPayload() method which allows you to pass any kind of data between threads, so you just need to call it in the worker and then use GetPayload() in the main thread to extract the information and process it.
However since wxWidgets 3.0 you have another way to do it with CallAfter(), which is especially convenient if you use C++11 (and you really should). This allows you to write the code you want to execute in the scope of the thread function, but it will actually get executed in the context of the main thread. So you could do this:
wxThread::ExitCode MyThread::Entry()
{
wxGetApp().CallAfter([this] {
wxTreeListItem root = m_frame->m_treelist->GetRootItem();
m_frame->m_treelist->CheckItem(root, wxCHK_CHECKED);
});
...
}
and it would actually work because the code inside the lambda would be run in the main thread. This is extremely convenient and you should do it like this, but just make sure you actually understand what does this do and that it still uses the same underlying mechanism of posting events to do its magic.
Disclaimer: I am relatively new to Qt and any type of programming that revolves around Threads and Networking. I have also adopted a lot of code from Qt Examples, API, and other online examples.
All code can be found on GitHub. This code is relatively as simple as it can get minus striping out GUI. I figure supplying it this way would help as well versus just pasting the code below.
I want to use and believe I need to use Threads as I need multiple clients send a request to the server, the server run some SQL code, then spit out the results back to the client (basically deriving a MySQL Server, but specific to what I am doing). Right now though, I am just working on learning the workings of it all.
With all that being said, as the Title states.. My client can connect to the server, the server sets up the thread, and will receive data (a String) through the readReady. After the data is read in, for right now I am just trying to echo it back to the client. It will do this, but only once. Then it spits out:
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QNativeSocketEngine(0x266cca92ea0), parent's thread is serverThread(0x266cca9ed60), current thread is QThread(0x266cac772e0)
I cannot send any further data to the server unless I have the client reconnect, then after the data is sent, it will do its job but then spit out the same error and cease functioning. I have tried quite a bit of different things, but cannot seem to fix the issue. I even tried setting up a SIGNAL/SLOT for this as suggested in API:
It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread that calls run(). This means that all of QThread's queued slots will execute in the old thread. Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread.
Anyway, any help would be greatly appreciated! My Code is below..
Server
ServerThread.cpp
// Project
#include "ServerDialog.h"
#include "ServerThread.h"
ServerThread::ServerThread(qintptr _socketDiscriptor, QObject *parent /*= 0*/)
: QThread(parent)
{
socketDiscriptor = _socketDiscriptor;
}
void ServerThread::run()
{
emit threadStarted(socketDiscriptor);
// Start Thread
clientSocket = new QTcpSocket;
// Set SocketDisc
if (!clientSocket->setSocketDescriptor(socketDiscriptor))
{
emit error(clientSocket->error());
return;
}
// Connect Socket and Signal
connect(clientSocket, SIGNAL(readyRead()), this, SLOT(readyRead()));
connect(clientSocket, SIGNAL(disconnected()), this, SLOT(disconnected()));
//// Loop Thread to Stay Alive for Signals and Slots
exec();
}
void ServerThread::readyRead()
{
QDataStream in(clientSocket);
in.setVersion(QDataStream::Qt_5_7);
in.startTransaction();
QString dataReceived;
in >> dataReceived;
if (!in.commitTransaction())
{
emit readyReadError(socketDiscriptor);
return;
}
emit readyReadMessage(socketDiscriptor, dataReceived);
echoData(dataReceived);
}
void ServerThread::disconnected()
{
emit threadStopped(socketDiscriptor);
clientSocket->disconnect();
clientSocket->deleteLater();
this->exit(0);
}
void ServerThread::echoData(QString &data)
{
QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);
out.setVersion(QDataStream::Qt_5_7);
out << data;
clientSocket->write(block);
}
So in ServerThread.cpp when echoData is called, that is when the error shows up and the Socket ceases functioning.
Any and all help will be appreciated. I know there are a few other posts regarding "Cannot create children for..." in regards to Threads. But I did not find any of them helpful. The one thing that I did find interesting but did not understand was maybe using moveToThread() but a lot of mixed comments on that.
I learn best through code examples along with explanation versus just an explanation or pointer to API. Thank you!
Most of Qt network functions are asynchronous; they do not block the calling thread. There is no need to mess up with threads if you are using QTcpSockets. In fact, creating a thread for every socket is an overkill, since that thread will spend most of its time just waiting for some network operation to finish. Here is how I would implement a single-threaded echo server in Qt:
#include <QtNetwork>
#include <QtCore>
//separate class for the protocol's implementation
class EchoSocket : public QTcpSocket{
Q_OBJECT
public:
explicit EchoSocket(QObject* parent=nullptr):QTcpSocket(parent){
connect(this, &EchoSocket::readyRead, this, &EchoSocket::EchoBack);
connect(this, &EchoSocket::disconnected, this, &EchoSocket::deleteLater);
}
~EchoSocket() = default;
Q_SLOT void EchoBack(){
QByteArray receivedByteArray= readAll();
write(receivedByteArray);
disconnectFromHost();
}
};
class EchoServer : public QTcpServer{
public:
explicit EchoServer(QObject* parent= nullptr):QTcpServer(parent){}
~EchoServer() = default;
//override incomingConnection() and nextPendingConnection()
//to make them deal with EchoSockets instead of QTcpSockets
void incomingConnection(qintptr socketDescriptor){
EchoSocket* socket= new EchoSocket(this);
socket->setSocketDescriptor(socketDescriptor);
addPendingConnection(qobject_cast<QTcpSocket*>(socket));
}
EchoSocket* nextPendingConnection(){
QTcpSocket* ts= QTcpServer::nextPendingConnection();
return qobject_cast<EchoSocket*>(ts);
}
};
int main(int argc, char* argv[]){
QCoreApplication a(argc, argv);
EchoServer echoServer;
echoServer.listen(QHostAddress::Any, 9999);
QObject::connect(&echoServer, &EchoServer::newConnection, [&](){
EchoSocket* socket= echoServer.nextPendingConnection();
qDebug() << "Got new connection from: " << socket->peerAddress().toString();
});
return a.exec();
}
#include "main.moc"
Notes:
This server has the ability to handle more than one client at the same time, since there is no blocking. The thread will just respond to the event that happens with the appropriate action; So, if that event was a new connection, it will create a new EchoSocket object to handle it and prints a statement out to qDebug(), and if that event was receiving something on a previously created socket, the same thread will echo received data back and close the connection. It will never block on a single connection waiting for data to arrive nor it will block waiting for a new connection to arrive.
Since you mention using some SQL queries in response for some connections later in your project. Please avoid threading since an SQL database connection in Qt can be used only from the thread that created it, see docs here. So, You'll have to either create a new database connection for each thread (and thus for each connection) in your application (and this is beyond just overkill), or switch later to a single threaded design.
In this section, I am explaining why threading does not work for you the way you are doing it:
You should not be declaring slots in your QThread subclass, Instead, use worker QObjects and move them to QThreads as needed.
The quote you have provided in your question is the exact explanation for why you get this warning. The ServerThread instance you create will be living in the main thread (or whatever thread that created it). Now let's consider this line from your code:
connect(clientSocket, SIGNAL(readyRead()), this, SLOT(readyRead()));
The signal readyRead() will be emitted from the current ServerThread instance (since the clientSocket object that emits it lives there), However, the receiver object is the current ServerThread instance, But that lives in the main thread. Here is what the documentation says:
If the receiver lives in the thread that emits the signal, Qt::DirectConnection is used. Otherwise, Qt::QueuedConnection is used.
Now, the main point of Qt::QueuedConnection is executing the slot in the receiver object's thread. This means that, your slots ServerThread::readyRead() and ServerThread::disconnected will get executed in the main thread. This is most likely not what you meant to do, since you'll end up accessing clientSocket from the main thread. After that, any call on clientSocket that results in child QObjects being created will result in the warning you get (you can see that QTcpSocket::write() does this here).
Mixed comments of movetothread are linked mostly to usage of it to move thread object to itself.
The quote hints that the members of QThread aren't designed to be called from worker. Strictly proper way to call signal would be by using worker object model, that was shown in Qt examples and explained a few times on QT-related blogs:
class Worker : public QObject
{
Q_OBJECT
private slots:
void onTimeout()
{
qDebug()<<"Worker::onTimeout get called from?: "<<QThread::currentThreadId();
}
};
class Thread : public QThread
{
Q_OBJECT
private:
void run()
{
qDebug()<<"From work thread: "<<currentThreadId();
QTimer timer;
Worker worker;
connect(&timer, SIGNAL(timeout()), &worker, SLOT(onTimeout()));
timer.start(1000);
exec();
}
};
worker constructed inside run() is "property" of the thread it created, so figuratively speaking, it is slaved to its context. The same effect maybe achieved if you create worker in other thread, then move it to this thread before connection was made. When you connect signal to slot of the QThread itself, you connect child thread to thread it was created by.
Use of
connect(&timer, SIGNAL(timeout()), this, SLOT(onTimeout()), Qt::DirectConnection);
or creating connection from your thread sometimes seems to achieve proper result, but not in this case, where you try use objects constructed in different threads together. Calling moveToThread(this) in constructor is a thing not recommended to do.
I need to update the content of a field on my QWidget via a JSON file (updated in real time). I've read about functions readLine() and readAll() of QFile, but when I try a loop like :
while(true):
jsfile.readLine()
creation of objects, update of values, display etc ...
I lost the focus on my window. But I want to keep the control of the application with my buttons and obviously to watch the evolution of the JSON values.
I have thought that Qt manages itself the events and keeps the focus on the current window, but like I've said, it's not the case.
Is there a good solution (multi threads maybe) to use my window while the application reads the file (with new informations in real time)?
(With the constraint "real time" I can't read the whole file every time and I've no choice about the format of this file)
Update
I tried the thread method.
So, I choose to create my thread instance into the main (with my main window) and connect here. But, when I run the program, I've this error :
no matching member function for call to 'connect'
Reader reader;
QObject::connect(controler, SIGNAL(ready()),
reader, SLOT(received()));
According to this error, I've thought that the reason was main don't inherits of Object, and so, I've move the connection ans the creation of thread instance into my main window.
Reader reader;
QObject::connect(reader, SIGNAL(newobject(QJsonObject)),
this, SLOT(displayJSON(QJsonObject)));
With this one, I've the same error while I've already connect lot of widget into this class without any error.
What can be the problem ?
Update 2
I've a solution when I give as argument my main window (controler) in reader's constructor and connect into this one but, if possible, I would an explanation for the previous problem.
The current problem that I have is that signals are emit well but slots are executed after the end the application (so after the end of the thread's execution and not during)
This isn't really the subject of this topic so we can close this one.
You can use QThread (Qt documentation: QThread) class to create a thread, which will read your file. The main thread will execute your GUI application and it will be available during file reading.
You can find a simple example in documentation for creating your thread:
class WorkerThread : public QThread
{
Q_OBJECT
void run() Q_DECL_OVERRIDE {
QString result;
/* ... here is the expensive or blocking operation ... */
emit resultReady(result);
}
signals:
void resultReady(const QString &s);
};
void MyObject::startWorkInAThread()
{
WorkerThread *workerThread = new WorkerThread(this);
connect(workerThread, &WorkerThread::resultReady, this, &MyObject::handleResults);
connect(workerThread, &WorkerThread::finished, workerThread, &QObject::deleteLater);
workerThread->start();
}
You can modify this example for your purpose. For example, WorkerThread for your task may be something like this:
class WorkerThread : public QThread
{
Q_OBJECT
void run() Q_DECL_OVERRIDE {
while(!stopFlag)
{
// read JSON file to QByteArray. Use QFile and QTextStream
// use QJsonDocument to read JSON content
// find what is new in JSON
emit signalSomethingNew(/*parameters*/);
QThread::currentThread()->msleep(/*timeout*/);
}
}
signals:
void signalSomethingNew(/*parameters*/);
};
At the end you must implement slot on your QWidget for signalSomethingNew(/*parameters*/) and make connection:
connect(yourThread, &WorkingThread::signalSomethingNew, youWidget, &YouWidget::yourSlot);
For working with JSON data: QJsonDocument
I'm interpreting your question as "my application is unresponsive whilst doing work" rather than "my focus jumped to another window" - please comment if you meant something different.
You have a choice of options:
Create and run a background QThread to do the work. Have it emit signals (connected to your widgets using Qt::QueuedConnection - the default) when it has results to display.
This is a good solution when the worker has a lot of computation to do, or needs all the input to be read before it can start. It works very well when the target system has processors available with no other work to do.
Use a QSocketNotifier to signal your GUI thread when some of the input becomes available (note that the name is misleading - it actually works on all kinds of file descriptor, not just sockets).
This is appropriate when the algorithm is simple and incremental - i.e. if a small chunk of input can be read and processed quickly.
Incorporate periodic calls to processEvents() in your algorithm:
auto *const dispatcher = QThread::currentThread()->eventDispatcher;
while (line = json.readLine()) {
doSomethingWith(line);
if (dispatcher)
dispatcher->processEvents();
}
This won't work unless you can modify the algorithm like this - if the loop is in somebody else's (closed) code, then you'll need one of the other solutions.
I have a multithreaded program that downloads and gets information from a website, then takes the info, creates a object that i then add to my GridLayout with a image.
I have thousands of objects that i need created and then added to my gridlayout, using 8 threads to get the information and those same 8 threads then create the objects and add them to 8 different grids.
After the program runs for about 20 seconds, i get a
QThread::start: Failed to create thread (The access code is invalid.) errors.
After another few more seconds i get some Runtime C++ Errors that hang and don't display a message.
What does this imply?
What confuses me, is that at this point, my threads are already created and im not actually creating more threads.. inside those threads though they are each creating Widget Objects and then im sending those to the Main Gridlayout..
I checked the amount of threads i have running (QThread:idealThreadCount) which returns only 8.
I'm multithreading to download the information from the sites, which then each records returns values back which i created into a Object to put into my GridLayout.
Im thinking because at that point, these objects all belong to the single thread, and not ever emit(finished()) until all urls are done, so its hogging something and causing this error?
Should i try MoveToThread and send all these objects back to the Main thread after the information is downladed and the new object is added to my gridlayout?
Does any of this make sense of what is happening, and if do you want me to post the code?
Thanks.
Edit:
Just tried moving the threads after creation, but learnt
QObject::moveToThread: Widgets cannot be moved to a new thread
Here is my creation of threads
void checkNewArrivals::createWorkers(QString url, QString category, QString subCategory){
QThread* thread = new QThread;
checkNewArrivalWorker* worker = new checkNewArrivalWorker(url, category, subCategory);
worker->moveToThread(thread);
connect(worker, SIGNAL(error(QString)), this, SLOT(errorString(QString)));
connect(thread, SIGNAL(started()), worker, SLOT(process()));
connect(worker, SIGNAL(finished()), thread, SLOT(quit()));
connect(worker, SIGNAL(result(QString,QString,QString,QString,QString,int, int)), this, SLOT(addItem(QString,QString,QString,QString,QString,int, int)));
connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater()));
connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));
thread->start();
}
Here is my worker class function that emits the results
void checkNewArrivalWorker::getHtml(QString url){
html = QString::fromStdString(Curl->getWebsiteHtml(url.toStdString()));
html = html.mid(html.indexOf("Goods List"));
html = html.mid(0, html.indexOf("footer"));
for (int i = 0; i < html.count("GoodsBox"); i++){
//blah blah blah blah
emit result(idLink, picLink, price, category, subCategory, row, col);
col++;
if (col == 5){
col = 0;
row++;
}
html = html.replace(itemRow, "");
}
}
Then i add the results to create a item and add it to a gridlayout
void checkNewArrivals::addToGrid(QGridLayout *layout, QString id, QString picUrl, QString usPrice, int row, int col){
checkNewArrivalItem* item = new checkNewArrivalItem;
if (item->setupItem(id, picUrl, usPrice) == true){
layout->addWidget(item, row, col);
};
}
These items work fine, until a overload of items i think.. not too sure why im getting this error.
Qt GUI objects cannot exist in any thread other than the main thread. The GUI objects need to be created and added to the layout in the main thread. You can still gather data from background threads, but you'll need to pass it back to the main thread for display. For that, I recommend using signals, as signal/slot connections are thread-safe by default.
Edit: Your new threading looks like it should work. However, I think you'd find it preferable to keep a specific number of threads running and delegate the work to them. For one, creating, starting, stopping and destroying threads is an expensive process. But more importantly, perhaps, is that you might just be creating too many threads.
Just to be really clear, QThread::idealThreadCount() is not the number of threads you have running, but is the number of threads your CPU can most efficiently handle. I'm guessing you have a quad-core CPU with hyperthreading, making it 8.
I think it's most likely that you're creating too many threads. This sounds a lot like the time when I mistakenly did that.
So basically what I have is a Qt application that has a main GUI thread and a worker thread.
The worker thread is something like this:
void Client::readResults(int msgqid, pid_t pid)
{
int ret;
msg_t message;
connect(this, SIGNAL(dataReceived(QString)), this, SLOT(updateDisplay(QString)));
connect(this, SIGNAL(doneProcessing(QString)), this, SLOT(updateStatus(QString)));
for (;;)
{
ret = msgrcv(msgqid, &message, MSGSIZE, pid, 0);
if (ret == -1)
{
showStatusBarError("msgrcv");
return;
}
if (ret > 0)
{
emit dataReceived(QLatin1String(message.info));
if (message.is_eof)
{
emit doneProcessing("Done!");
break;
}
}
}
}
All it does is it reads from a message queue and emits a signal that causes a QPlainTextEdit widget from the main GUI thread (that spawned this thread) to call appendPlainText(message.info) so that the data received from the message queue is appended to the widget.
The problem is if I'm reading huge chunks of data from the queue (it's actually a text file around 30MB or more), the whole GUI just hangs until the worker thread finishes. Is there a way to make it not hang and for the user to actually see the QPlainTextEdit widget scrolling as it received data from the worker thread?
Thanks!
I had a similar problem before. In my case, and from my experience, the Signal/Slot System seems to lock the program flow. When you read in a lot of data or frequently read in some data it will naturally cause the GUI to slow down.
What worked for me was to use model-based input, which allows a steady and smooth update.
You might want to consider relocating the input so that you can directly read from the input to the GUI?