multithreaded gui updates

[ugluk]

I need to update the GUI from multiple threads. So far I've taken the following approach:


connect(this, SIGNAL(setGUILabel(QString)), label, SLOT(setText(QString const&)), Qt::QueuedConnection);

and it works... What bothers me is that the argument of the signal is of QString type (so that I make a copy of the string in the signal issuing thread), but the argument of the slot is QString const&. Is this mixing of references and object types allowed by Qt?

[wysota]

Two things. First is that you are not updating the gui from multiple threads, the gui is updated from one thread only. Second, signals undergo normalization procedure, passing const reference and copy results in the same normalized signature, so you don't have to worry. You can switch your two signatures (use const reference in the signal and copy in the slot) in your connect statement and it will still work.

[ugluk]

Well, I can't switch the signatures, as the slot signature inside QLabel is fixed. As for updating the GUI from multiple threads: I'm emitting the signal for that reason.

[wysota]

Well, I can't switch the signatures, as the slot signature inside QLabel is fixed.
No, you don't understand. I mean that instead of:

connect(this, SIGNAL(setGUILabel(QString)), label, SLOT(setText(QString const&)), Qt::QueuedConnection);
you can write:

connect(this, SIGNAL(setGUILabel(const QString &)), label, SLOT(setText(QString)), Qt::QueuedConnection);
or even:

connect(this, SIGNAL(setGUILabel(QString)), label, SLOT(setText(QString)), Qt::QueuedConnection);

You don't need to modify the methods themselves.

[ugluk]

I know that QString copies are shallow, when possible, but I think references are still better than copying. I think what you describe is counterintuitive - if a slot accepts a reference, then Qt should actually deliver one, in my opinion. Where can I read more on signal normalization?

[wysota]

You want a delayed invokation, you can't deliver a reference because it might not exist at the time when the slot is executed. All delayed calls cause data serialization and deserialization. Besides, I'm not talking about anything related to how a method is actually called. I'm only saying "const QString &" and "QString" will be both normalized to "QString" when signal and slot signatures are being compared.