[PyKDE] My thinking still wrong?

[Andreas Pakulat]

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.