Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 4

Qt-interest Archive, May 2007
GUI basics + multithread signal/slot comunication


Message 1 in thread

Hello I have a couple of questions...

A) I bought the book "C++ GUI programming with Qt4", but it seems to me it is 
targheted to people with already a bit experience in GUI programming. My 
problem is not plain C++ (I have a very good book for it!), but rather GUI 
related issues.. I have no idea of what a "X server" ( a server??) is, nor 
what "rendering" or antialias means.. Can someone suggest me where I can have 
an introduction on "generic" GUI programming..??
B) My second question relate to signal and slot comunication between the GUI 
thread and the (unique for now) working thread.
The working thread compute a very long job (hours) and in the meantime the 
user on the GUI would like to get an idea of what is happening there..

So the GUI emit a signal to request something (in my case an image), the 
w.thread has a slot to accept the request and process it and eventually emit 
a signal with the result to the GUI that has a dedicated slot to collect it 
and show it.

My questions are:
b1) Does this approach seems rasonable to you, expert guys? ;-)
b2) If the working thread is doing his own business, when it will process the 
original signal coming from the GUI???
b3) Does a full signal/slot approach free me from using that "strange things" 
called mutex and semaphores, or I still need them?? 

thanks for your help..
      Antonello

-- 
 [ signature omitted ] 

Message 2 in thread

Hi,

On Friday 18 May 2007, Antonello Lobianco wrote:
> A) I bought the book "C++ GUI programming with Qt4", but it seems to me
> it is targheted to people with already a bit experience in GUI
> programming. My problem is not plain C++ (I have a very good book for
> it!), but rather GUI related issues.. I have no idea of what a "X server"
> ( a server??) is,

This might be a good start:
http://en.wikipedia.org/wiki/X_Window

assuming you work with Linux or Unix. If not, replace all references 
of "X11" or "X-Server" in the book by "Windows/Apple/whatever GUI Engine".

> nor what "rendering" or antialias means.. Can someone 

Render:
http://www.m-w.com/dictionary/render (Meaning no. 4)
In GUI works it usually means to calculate the correct display layout and to 
actually display the data.

Antialiasing:
Smoothing of fonts/lines/curves, so they don't look like being cut out with 
a jigsaw.
http://en.wikipedia.org/wiki/Antialiasing

> suggest me where I can have an introduction on "generic" GUI
> programming..??

Google. The Qt Tutorial. The book you already have.

> So the GUI emit a signal to request something (in my case an image), the
> w.thread has a slot to accept the request and process it and eventually
> emit a signal with the result to the GUI that has a dedicated slot to
> collect it and show it.

IMHO this is the wrong way around. While your worker-thread is still working 
it will not have a chance to access its event loop (except if you 
constantly poll it). Better to let the worker thread emit a signal from 
time to time to update the GUI without the GUI asking for the update. The 
difficulty is of course to find a good interval for the updates: usually 
more than 5 times a second is too much, depending on what you do the best 
interval could be between 5Hz and once in 10 seconds.


	Konrad

Attachment:

Attachment: pgpwO6kc5QU5J.pgp
Description: PGP signature


Message 3 in thread

Thank you. It make much more sence.
I had problems emitting from the working thread to the GUI thread an image 
pixel by pixel, but I solved cashing it on the working thread and then 
emitting it all in one go.

Thanks again..
      Antonello

On Friday 18 May 2007 10:22, Konrad Rosenbaum wrote:
> IMHO this is the wrong way around. While your worker-thread is still
> working it will not have a chance to access its event loop (except if you
> constantly poll it). Better to let the worker thread emit a signal from
> time to time to update the GUI without the GUI asking for the update. The
> difficulty is of course to find a good interval for the updates: usually
> more than 5 times a second is too much, depending on what you do the best
> interval could be between 5Hz and once in 10 seconds.

-- 
 [ signature omitted ]