[PyQt] Re: PyQt4 and threading

Andreas Pakulat 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
> hierarchy.

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.

Andreas

-- 
You are going to have a new love affair.


More information about the PyQt mailing list