[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] Using threads with QtRuby
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2010-02-08 20:29:35
Message-ID: 201002082129.35273.cberger () cberger ! net
[Download RAW message or body]

On Monday 08 February 2010, Richard Dale wrote:
> > And there is two more things I wanted to say on this topic.
> > First, I were wrong about using widgets from non-gui threads - it still
> > fails. You could change the window title, for example, but still can't
> > paint or change value of progressbar and so on.
> 
> Yes, QObjects are associated with a certain thread, and I think only the
>  main  thread can do rendering otherwise it would be hard to coordinate.
> 
To be accurate, in Qt, what needs to be done in the main thread are operations 
that call to X11, since libxcb is not thread-safe (not sure for windows/macos 
x), which means QPixmap and QWidget should only be used in the main thread. It 
is one of the reason why you should not render on a widget outside the 
paintEvent (the other is performance). But nothing prevent you to prepare a 
QImage outside the GUI thread, and to then draw it on your widget in the paint 
event. And when you want to trigger rendering on a widget, you use 
Qt::Widget::update(), which is, as far as I know, thread safe.

When you want to change the value of a progress bar, what you can do is use a 
signal/slot, since it is possible to connect two objects in different threads, 
and by default (as seen in [1]), the slot will be executed in the object 
thread, meaning the main GUI thread for a QWWidget.


[1] http://doc.trolltech.com/4.6/qt.html#ConnectionType-enum

-- 
Cyrille Berger
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]