Re: [Discuss-gnuradio] Bug in waterfall window "Time scale" GUI control

[Marcus D. Leech]

On 04/28/2010 09:33 PM, Johnathan Corgan wrote:
> On Wed, Apr 28, 2010 at 18:15, Marcus D. Leech <address@hidden> wrote:
>   
> Marcus, thanks for all the testing/fixes/ideas for the GRC/gr-wxgui
> code.  You're uncovering places where we've (well, *I*'ve) been less
> than...diligent in  coding things.
>   
Diligence?  Diligence is for the weak!  :-) :-) :-)

> I really need to get you set up as a git-based contributor so we can
> easily test/merge what you're doing.
>
>
>   
Yup, that would probably be good.

I've done a number of things this evening to my own code base:

    o added a new method in gr_file_sink_base, ::set_unbuffered() that
causes the ::work method to
       always issue a fflush() after the write loop.  This is critical
for outputs to named pipes
       where the input data rate is modest--even when you're writing
complex-floats, it can take
       a long time to fill up a stdio BUFSIZ.     One would be tempted
to add a function that
       places a call to setvbuf(), with an appropriately small buffer,
but setvbuf() can only be
       used properly before any I/O has taken place on the file stream.

       I updated the file_sink.xml  for GRC to match the new method, in
that there's a creation-time
       option to make this file_sink unbuffered.


     o Used the "prefs" functionality to control a few things in the
wxgui sinks:

         o A boolean 'run_always'  controls whether your plot-type
things run all the time, or only when visible

         o A long 'trig_mode' that sets the default trigger mode when an
OSCOPE comes up.  No fancy converter
            here, it has to be between 0..3 or lord alone knows what
will happen.

         o a string 'waterfall_color'  (notice how I deferred to the
American spelling of colour to maintain
            consistency with the code :-) ), which sets the default
waterfall colour-map on init.

This is an OK, but not wonderful, way to do this.  Ideally, of course,
all the functionality within a wxgui
    object should be programmatically accessible, but I admit that
making that happen is a daunting
    task.  The params list for these things is already really freaking
long, and we'd end up adding probably
    10 new params, which has implications for GRC, etc, etc.


I wonder how easy it would be to tweak the "prefs" module to support
app-specific preferences?  Hmmm.

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org