On 04/28/2010 02:18 PM, Johnathan Corgan wrote: > On Wed, Apr 28, 2010 at 00:06, Marcus D. Leech <mle...@ripnet.com> wrote: > > >> It looks like when a graphic sink isn't visible, it doesn't "run". >> > This was an optimization for performance. One can quickly run out of > CPU by having multiple notebook tabs with display sinks in them. > > It could be made configurable, but there is a fair amount of surgery involved. > > Johnathan > > > This raises another point--quite a lot of the runtime behaviour of the graphic sinks is *only* controllable via the GUI controls, and there's no programmatic way to set them (that I could find--I'd be pleased to be proven wrong).
For example, the Trigger mode, time offset, etc, are only controllable via the GUI. You can't even set them at init time when you create the object. A usable, consistent, mechanism needs to be in place to make sure that all of the behaviour that is controllable using a GUI control can also be controlled programmatically (which also implies, can be saved in a config file, etc, etc). I put in a *HORRIBLE KLUDGE* into scope_window.py to allow for the oscope to come up with gr_TRIG_MODE_STIPCHART set on init, but I'm not going to propagate that kludge into the repos :-) I used an environment variable. When it's creating the object, it checks to see if OSCOPE_TRIG_MODE is set to STRIPCHART, and configs the oscope appropriately. But golly, that's, ahem, ugly and braindead. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
