[PyQt] processEvents on QlistWidget operations does nothing

Andreas Pakulat apaku at gmx.de
Sun Jan 27 19:26:18 GMT 2008


On 27.01.08 19:37:05, P. Mathé wrote:
> Le dimanche 27 janvier 2008, Andreas Pakulat a écrit :
> > 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.
> 
> I did it : the code is awfully ugly just to replace 1 line of code

Its not about replacing 1 line of code, its about properly designing
your applications business logic. Moving heavy work into a thread is the
right thing to do (or separate process). QApplication::processEvents is
the ugly hack for those who are not able to use threads properly.

Andreas

-- 
You will be reincarnated as a toad; and you will be much happier.


More information about the PyQt mailing list