[PyKDE] My thinking still wrong?

[David Boddie]

On Sun Feb 26 19:31:09, Andreas Pakulat wrote:
> On 26.02.06 18:24:27, David Boddie wrote:

> > 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 ;-)

Unfortunately, I've done this with popen2.Popen3 objects from the Python
standard library, but that can also be difficult to manage.

> 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...

Although I've just recommended that approach, I tend to get quite worried
when I see processEvents() being used in code. There's a temptation to use
it all over the place instead of writing code that's suitable for the API,
using signals and slots, and letting Qt get on with handling the events.

I imagine it gets used more than it should in many cases because people
think that it's a lot of work to set up signals and slots, or because that
approach doesn't fit in with the way they imagined the control flow should
be, especially if the original code was used in a command line tool.

> > 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.

There's always great fun to be had when running processes that expect
input on their stdin, and which write creatively to both stdout and stderr.
Things get better when the exit status code turns out to be not-exactly-
standard. I really feel for the people who write graphical front ends to
peculiar interactive command line tools that have to be so careful with
their inputs and outputs.

> > 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.

It's available at

    http://www.diotavelli.net/PyQtWiki/Capturing_Output_from_a_Process

See the other code snippets for more inspiration:

    http://www.diotavelli.net/PyQtWiki/SampleCode

Have fun (and feel free to add some comments),

David