[PyKDE] Keeping the GUI from freezing

[Tony Cappellini]

> If your thread inherits QObject somehow, you can just do:

Sorry- this thread has gotten complicated.
At the moment, I'm not using threads. However, in earlier versions of
the program I was using a thread to process popen() to grab the target
apps output.
Now that the target app is using logging, popen() doesn't work (wont
catch the output).

So currently, I'm not using threads or popen. I'm using the ugly hack
which does an exec, which was recently posted- as a work around not
being able to catch the output of the logger.



> self.emit(QtCore.SIGNAL("nameYourSignal()") )

With your reply in mind- If I need to use threads, I will probably use
Qt threads.
However, I don't know what signal to use in your example.
Are you suggesting I create an arbitrary signal- not assoicated with
any particular widget?

> You can give arguments to it also.  Then just connect slots up to the signal.
> If your thread doesn't for some reason, then you need to give it a QObject of
> some sort that it can call.
>
> Anyway, in #qt they tell me signals and slots are thread safe.  I haven't
> tested it yet, but will be testing it soon.  :)
>
> Dave
>
> > Paul Giannaros ceruleanblaze at gmail.com
> > Tue Feb 13 19:19:46 MET 2007
> >
> > > Does anyone have a Python example of how to use a Thread to keep a gui
> > > from becoming unresponsive?
> >
> > Well, before you turn to threads I'd suggest that there are far simpler
> > ways to go about what you want to do. There are may ways to start a process
> > asynchronously so that the GUI remains responsive as usual. You can use the
> > os.popen function, for example; or the subprocess module; or Qt's QProcess.
> >
> > _______________________________________________
> > PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
>