[PyQt] Re: PyQt4 and threading
apaku at gmx.de
Thu Oct 15 16:28:19 BST 2009
On 15.10.09 13:17:38, Ole Streicher wrote:
> Andreas Pakulat <apaku at gmx.de> writes:
> > On 15.10.09 09:22:03, Ole Streicher wrote:
> >> >> item.setBrush(QtGui.Brush(QtGui.QColor(...)))
> >> Jason H <scorp1us at yahoo.com> writes:
> >> > GUI operations can only be done in the main thread.
> >> Is setting the brusch of a QGraphicsRectItem a GUI operation?
> > Possibly, the scene.update() is definetly going to trigger GUI
> > operations.
> But, the crashes are *not* in the scene.update(), but in the
> item.setBrush() call. This is funny, since QGraphicsRectItem does not
> even dervive from QObject and is therefore not part of the Qt object
Deriving from QObject doesn't make any operations on that class gui
operations. In fact you can use various QObject subclasses without any GUI.
Also, I said "possibly", I didn't actually check it, but I wouldn't be
surprised if changing a brush on an item is considered a GUI operation.
> > However if it really is too slow, you can simply split up the work into
> > chunks and let the event loop run in between so the GUI keeps responsive.
> > One way to achieve this is by using a QTimer which fires regularly and then
> > work on a chunk in the connected slot.
> That sounds like creating my own "cooperative" multitasking structure
> which sounds very complicated and errornous (think of Windows 3.1 which
> already used this model).
I have no idea about windows 3.1. However thats a relatively normal thing
to do if you have lots to do and you don't want to block the event loop.
You are going to have a new love affair.
More information about the PyQt