Re: [Discuss-gnuradio] window sizing issue

[ematlis]

Michael-

thanks very much for your help!  Your changes have fixed the "control 
buttons covered" issue.  I'll have to study what you did; I don't know any 
wxPython at all and as you've mentioned it's not easy to wade through 
existing documentation.

Two other questions-

1) do you happen to know where the default values for the control buttons 
are set?  I'd like to change the time scale from 100us/div to 1ms/div and 
to set the Autorange to "on" by default.

2) do you know how to convert the integer values on the third window 
(time-series) to actual voltage values as measured by the adc?  It must be 
a function of the internal gain and offset.  I need to know these 
eventually; this application is supposed to measure physical voltages, not 
just produce sounds.

thanks again,
eric

************************************
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355

On Thu, 15 Mar 2007, Michael Dickens wrote:

> On Mar 15, 2007, at 5:15 PM, address@hidden wrote:
> > I've got an application with 3 plot windows and a control area in the 
> > bottom. Depending on the screen resolution, the control area on the bottom 
> > is "covered" by the lowest of the 3 plot windows.  The applicatoin works 
> > fine at 1600x1200 but less well at 1440x900, and certainly at lower 
> > resolutions the control boxes are getting covered.
> >
> > What can I do so that even at lower resolutions I can see the entire 
> > application?  I've tried adjusting the middle numeric field 
> > (vbox.add(self.scope.win, 4, wx.EXPAND)) in the vbox.add entry from 4 to 0, 
> > which helps for 1440x900 but this doesn't work for all resolutions and I 
> > don't know what this value represents anyway.  Is there a recommendation 
> > for making my application resolution-independent?  I've attached the 
> > python-code.  Any advice is appreciated!
>
> I've been studying GUI design recently, and I can tell you that it's not 
> simple learning WX or wxPython as documentation really isn't very good 
> (IMHO).  Does folks have particular references (online tutorial, book, PDF) 
> that they really like?  I could use some pointers ... I've seen those 
> provided by the WX and wxPython projects, and Google'd various others, but 
> none really do justice to all the methods and variables for even such 
> "simple" things as a BoxSizer.
>
> I think this is correct: The "0" or "4" you're referring to is a "weight" of 
> the particular added object.  The "weight" is taking into account when the 
> BoxSizer [0] determines how big an object should be; "0" weight (I think) 
> means to not consider this object in the sizing but rather instead to just 
> allocate its actual size (in pixels).  Tweaking this value helps only so 
> much, as objects can get only so small and screens only so large.  Each 
> object has a property, something like "minimum size"; some of these are 
> straight forward to set while others seem to be less so if not impossible.
>
> In the case of the "fftsink" GUI, the default frame size is (X,Y) = (640, 
> 240), as found in gr-wxgui/src/python/fftsink.py , and you can change this in 
> the call to "fftsink.fft_sink_c" with "size=(50,50)" or whatever you want. 
> Ditto for fftsink2.py.  Then you'll want to change the "weight" in the 
> "vbox.Add" call to 1 for each of these.
>
> That for "scopesink" is also (640, 240) [gr-wxgui/src/python/scopesink.py], 
> except that this value doesn't actually get used for anything (oops, bug 
> alert).  The "scopesink" also has some extra GUI stuff below it that doesn't 
> seem to be set to EXPAND; nor is "size" passed around to any of the classes 
> that actually create the GUI objects.  Thus some work needs to be done on the 
> scopesink classes stuff in order to get "size" to work.
>
> Once the scopesink is corrected (as appended [1]), then you'll probably want 
> (in your am_rcv_plasma.py) to vbox.Add them with a weight of 1, and 
> everything else with a weight of 0.  At least for me, this looks OK at down 
> to around (X,Y) = (750,525) ... nothing special that small, but it does work.
>
> [0] The BoxSizer 'vbox' to which you refer is a means for placing objects 
> into a GUI with minimal user defined parameters; this particular one is a 
> "vertical box" only, which means that items are added from the top of a 
> window towards the bottom, in rows.  Each row can have a different number of 
> columns, each of which is generally a BoxSizer in its own right (a 
> "horizontal" one).
>
> [1] I've appended updated files, with corrections for these issues.  Place 
> them in the same directory before trying to execute your "am_.." script since 
> it now depends on the fftsink_mod script being in that same directory.  I'll 
> think about what should really be done to scopesink to get it working 
> properly, since this is just a quick fix for an obvious problem but it's not 
> "ideal" I don't believe.