Re: [Discuss-gnuradio] wxPython programming

[Eric Blossom]

On Wed, Feb 23, 2005 at 05:58:08PM -0500, James Cooley wrote:
> Hi Chuck/All
> 
> I have a rough version of exactly what you seek that I did today! See 
> attached. Not cleaned, no guarantees, but suggestions/improvements 
> welcome. I have a wrapper class, gr_powermate which wraps the standard 
> python powermate lib posted recently.
> 
> Also, I got tired of setting and calculating a separate front-end freq. 
> So with this, there is ONE notion of freq. THere's a func that sets the 
> front end and usrp accordingly.
> 
> This amounts to a nearly full featured scanner.

Great job!


> The gist of your problem was solved by using a wx EVT_IDLE, like so:
> 
>        # add an idle handler
>        self.frame.Bind(wx.EVT_IDLE, self.onIdle)
> 
> Be careful. So the onIdle handler is called when ever wx isn't busy. wx 
> is busy a lot, so make sure you don't block for too long. There's 
> probably a more elegant way to not block. For me, I just made sure the 
> powermate stuff was quick! It scans for 50ms at a time then gives up.


I strongly recommend AGAINST using EVT_IDLE.

You really don't want to poll when there's a better way to do it.  
And there's almost always a better way to do it.

Start a separate thread that loops doing a blocking wait for an event
from the powermate.  When you get an event that's interesting, send an
event to your main gui thread using wx.PostEvent.

You set up the handler for your new event and let the callback handle
it.  This is all thread safe, works great, and doesn't waste any CPU
cycles.

If you take a look at the guts of fftsink.py it implements this
strategy.  There's a class input_watcher that does blocking reads on a
pipe.  When it gets something it creates a DataEvent and posts it with
wx.PostEvent.  A minor variation on this theme will handle the the
powermate cleanly and efficiently.

Eric