Thank you John and Pietro for your observations and advice. Because of them, I did some rethinking of my program. Threading has worked okay for a couple of years in this program as I continually improved it. But the GUI I started with had to be useful while recordings were taking place. I use the to tune a radio receiver according to a schedule and record what was found there, and I needed to be able to make adjustments on the fly. I use a different radio and GUI now, and except for Start and Quit buttons, the GUI is just to supply information. So I don't need threading or the timeouts to pause the program until the recording is finished. I'm not thrilled with seeing the GUI go dark during recording, but it's okay. Now there is only one 5-second timeout to check the clock between scheduled recordings.
Is there a better way to monitor the clock? I have to use time-of-day rather than time periods, and I haven't figured out a better way than executing time.gmtime() every 5 seconds. westli --- On Thu, 1/21/10, Pietro Battiston <[email protected]> wrote: > From: Pietro Battiston <[email protected]> > Subject: Re: [pygtk] gobject.timeout_add() > To: [email protected] > Date: Thursday, January 21, 2010, 1:56 PM > Il giorno gio, 21/01/2010 alle 08.56 > +0100, John Stowers ha scritto: > > On Wed, 2010-01-20 at 21:22 -0800, dj wrote: > > > I hope this is the right place to ask this... > > > > > > I have a python program (using Glade to create > the gui) that periodically launches ecasound to make audio > recordings of various lengths. In order to keep the > gui viable, ecasound runs in a separate thread. In > order to keep the program from getting ahead of itself and > trying to launch ecasound before the current recording > process has finished, I use gobject.timeout_add() for the > length of the recording (plus a second or two for safety). > > > > > > Most of the calls to gobject.timeout_add() are in > separate functions with different intervals. All but > one of them work. The last one only works if > gobject.timeout_add(..., ...)/return False is appended to > the end of the function that needs it, rather than calling > it. > > > > This doesn't sound like a particuarly nice design, > > More specifically: are you sure you need threads at all?! > subprocess.call will block the GUI, but subprocess.Popen > won't. > > Pietro > > _______________________________________________ > pygtk mailing list [email protected] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://faq.pygtk.org/ > _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
