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

List:       pykde
Subject:    Re: [PyQt] processEvents on QlistWidget operations does nothing
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2008-01-27 17:32:08
Message-ID: 20080127173208.GD5033 () morpheus ! apaku ! dnsalias ! org
[Download RAW message or body]

On 27.01.08 16:45:36, P. Mathé wrote:
> I am sending you this message, originally sent to the PyQt mailing list, as it \
> seems, according to Phil's answer that the problem lies within Qt. As suggested by \
> Phil, I changed the program to make the urllib call from within a different thread, \
> but, if it partially solves the problem, it repaces one line of code by  more than \
> fifty, makes the code almost unreadable, and disconnect the QListWidget from the \
> QProgressBar updates. (the new code is at your disposal). My point I that I just \
> want that QListWidget works as expected , i.e. that when I say "addItem(...)", I \
> see the item in the UI, now, not later , who knows when.

Uhm, the QListWidget does have the item immediately, however the
repainting only happens on the next run of the event loop. Calling
QApplication::processEvents is known to break in certain situations, any
longer-taking operation that shouldn't block the UI simply belongs into
a separate thread or process. Its usage is specifically for those who
know what they're doing.

Most of the time you're far better off writing a short QThread subclass
that does the "hard work" and sends either a custom event or simply a
signal using Qt::QueuedConnection.

Last but not least: If you want Qt behaviour to be changed, you need to
write a bugreport to Trolltech.

Andreas

-- 
Don't hate yourself in the morning -- sleep till noon.
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt


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