None-GUI thread call widget method cause error

[luochen601]

I use QListWidget for logging.
If call this method within GUI thread, it runs OK.
But if call this method from none-GUI thread, it throws error below:

QObject::connect: Cannot queue arguments of type 'QItemSelection'
(Make sure 'QItemSelection' is registered using qRegisterMetaType().)

The problem is I had never connect signal/slot with QItemSelection parameter.
I guess it happend after executing setCurrentItem() and setSelected().
So, how to call this method from none-GUI thread succussfully?

void MainWindow::updateLog(const QString& log)
{
QListWidgetItem* newItem = new QListWidgetItem;
newItem->setText(log);
ui->logList->addItem(newItem); // QListWidget
ui->logList->setCurrentItem(newItem);
ui->logList->scrollToItem(newItem);
newItem->setSelected(true);
}

[wysota]

You can't access any widgets directly from worker threads. Use signals and slots that are thread-safe to communicate with the main thread so that widgets are called from within its context (in other words make your updateLog() a slot and invoke it using signals and slots or QMetaObject::invokeMethod() with Qt::QueuedConnection).

[luochen601]

Use signals/slots is a good idea, but it slower than direct call when response speed is my first consideration. A simple example is vedio data transfered via callback function, if use signals/slots, the real-time can not be guaranteed or flicker will appear too. So how to solve speed need?

[tbscope]

Signals and slots are not slower than directly calling a function, that's just in your head or you did something very inefficiently.
But, you can also use events.

By the way, updating a list in real time IS inefficiently. The users of your program will not be able to follow it anyway.