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 > > Last but not least: If you want Qt behaviour to be changed, you need to > write a bugreport to Trolltech. Thank you, I just did it > > Andreas > Pierre _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
