On 26.02.06 18:24:27, David Boddie wrote: > On Sat, 25 Feb 2006, Andreas Pakulat wrote: > > On 25.02.06 09:55:18, Tina Isaksen wrote: > > > > > So I guess I've fallen in the trap of old-time thinking again... > > > > This time it's actually not python-specific "wrong-thinking" ;-);-) This > > would've happend to you in C++, Java and any other threaded-language > > with a threaded-toolkit like Qt. > > I'm not sure I'd put it that way, but I know what Andreas is saying. > Basically, in the doUpdateSources() method, Qt doesn't update any of the > widgets until you return from the method. Actually, it could take the > opportunity to refresh them, but I suspect that the updates are queued > until it regains control (in the event loop).
Right, Qt always uses PaintEvents to do updates of the GUI, never direct drawing - at least for the builtin widgets and as long as you don't overwrite update() on a QWidget-subclass. And as it uses PaintEvents it collects all those until the next loop occurs, decreasing the number of paints done and thus "increasing" the drawing-performance. > > 2) put the "work" into a separate Thread (i.e. the hole > > commands.getoutput which takes time) and communicate between the > > mainTextWindow and the new Thread via Event's. But befor doing so (and > > that is why I'm so brief here) you need to read some basics about > > threading, so you don't shoot yourself in the foot with it (for example > > never trigger drawing-operations outside the gui-thread). I don't have > > any book title or tutorial or some such at hand to recommend, sorry. > > Many people regard threading as a fairly advanced technique, although > Python's own threading module makes it look almost trivial. I find Qt's own threading-implementation quite easy to use too. I managed to not shoot myself in the foot, but it was only to have a progress-bar update while the work-loop runs in a separate thread. Here of course I could've also worked with processEvents, as I do have a loop already for the real work, but I figured it's a good and not too complicated way to introduce myself to threads ;-) > However, it > can introduce even more ways to shoot yourself in the foot. Another > option is: According to a recent discussion on either kde-devel or kde-core-devel you can shoot yourself into the foot with processEvents as well. Because this processes all events, not just PaintEvents. It also processes any Mouse-Clicks, keyboard-events and so on... > 3) Run "apt-get update" in another process, using either QProcess or > a Python standard library module. QProcess will execute a command > with arguments, and lets you read the output and errors as they > become available. There are ways of monitoring the command's > status and collecting the output. For the case presented this works, because apt-get updates it's output and as it already is a separate application it's just natural to use QProccess (or the python equivalent). However if you'd deal with a program that doesn't use stdout/stderr to provide some "state" information you'll have the same problem again. > Anyway, I'll put a more complete example on the Wiki because I > encountered a few more problems with this approach, and I want to show > some code that's as clear as possible. That'll be helpful for people, good work. Andreas -- Do something unusual today. Pay a bill. _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
