How to use separate threads for pushbuttons in QT (like SwingWorker in Java)

[artt]

"Trivial to do with a signal from the thread connected to a slot in the label" -- it is not so trivial for me.
I have looked for signals yesterday, and saw such sample
...Thread.h
signals: void signalmethod();
public: run();
then in thread.cpp
Thread::run() {
signalmethod();
} but I did it with static method. But here is non-static one?? what kind (how it should look like) of signal I shpuld use?
2. what 2 last point?

[anda_skoa]

I have looked for signals yesterday, and saw such sample

Right, just declare a signal and emit it in run.
The code creating the thread object can then connec this signal to its own slot or to the slot of another class.

E.g. if you had a signal like this

signals:
    void updateText(const QString &text);

signals:
    void updateText(const QString &text);

To copy to clipboard, switch view to plain text mode 

one could directly connect it to a label that should show that text

connect(thread, SIGNAL(updateText(QString)), label, SLOT(setText(QString)));

connect(thread, SIGNAL(updateText(QString)), label, SLOT(setText(QString)));

To copy to clipboard, switch view to plain text mode 

2. what 2 last point?

- don't call any methods of Lister in the threads
- put code that you want the threads to execute into the thread classes

[artt]

connect(thread, SIGNAL (update(QString)...) -- then I need to make the Qtextedit (Qlabel) field the member of Thread class -but other Qbuttons will be the Lister members - as well as the layout widget...
But it need to be composite (sorry - it should call - solid or indivisable to be more apt), how one widgets would be in one gui, the others - in another??

[anda_skoa]

connect(thread, SIGNAL (update(QString)...) -- then I need to make the Qtextedit (Qlabel) field the member of Thread class

Nope.

Cheers,
_

[artt]

So how? In updatetext() I need to use Qtextedit field, and how I use this field without Lister object creation, or I shoud create Qtextedit in Thread object - but it shoud be in GUI-thread (to avoid ASSERT failure).
I did not used sognal emitting never.

[anda_skoa]

The thread emits the signal, the widget receives it.
You connect in Lister, when you've created the thread instance, before starting it.

So the widget can either be Lister itself or one of its members.
No need to have a member in the thread.

Emitting the signal is just

emit updateText(someQStringVariable);

emit updateText(someQStringVariable);

To copy to clipboard, switch view to plain text mode 

Cheers,
_

[artt]

How can I use QTextEdit textview in signal without creating Lister object, as it is the part of Lister class?

[anda_skoa]

You either connect to a slot of the text edit itself or to a slot in Lister and the call setter methods on the text edit from that slot.

Cheers,
_

[artt]

I cannot suggest how? Would you? Either way I need Lister->textview or the most simple Lister::textedit..

[anda_skoa]

I cannot suggest how? Would you? Either way I need Lister->textview or the most simple Lister::textedit..

Lets assume the slot is a method of Lister.
Then you can just address any member with its name.
Just as you would in Java.

Cheers,
_

[artt]

What kind of signal should be- declaration and definition; Anyway it should be connected with the button - renderdirectly (or from file) - so I need anyway the object of Lister.
So if I add signal I need Lister object - so task appear more complex - and Slot is also Lister function and need its object if non-static.

[anda_skoa]

What kind of signal should be- declaration and definition

Comment #100 has an example for a declaration.
The definition of a signal is handled by MOC, nothing to do for you.

Anyway it should be connected with the button

QPushButton has a setText slot, so that would work just like for a label.

So if I add signal I need Lister object

Not sure what you mean.
You don't need a Lister object to add a signal to the thread class.

You don't need a Lister object to connect if there is some place other than Lister that knows both the thread object and the receiver object.
But Lister should have both, so it is the best place to put the connect into.
And you already have an instance of Lister, so no new thing required.

and Slot is also Lister function

Not necessarily as you can connect to any other object that has a slot matching the signal.

However, since your target for the signal seems to change a lot (first you had a label, then a text edit, now you've asked about a button), it might be easier to just connect to a slot in Lister and handle whatever UI update from there.

Cheers,
_