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. _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
