[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] window sizing issue
From: |
ematlis |
Subject: |
Re: [Discuss-gnuradio] window sizing issue |
Date: |
Fri, 16 Mar 2007 12:01:30 -0400 (EDT) |
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.
- [Discuss-gnuradio] window sizing issue, ematlis, 2007/03/15
- Re: [Discuss-gnuradio] window sizing issue, Michael Dickens, 2007/03/15
- [Discuss-gnuradio] window sizing issue, Michael Dickens, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue,
ematlis <=
- Re: [Discuss-gnuradio] window sizing issue, Michael Dickens, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue, Eric Blossom, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue, ematlis, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue, Eric Blossom, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue, ematlis, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue, Eric Blossom, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue, Matt Ettus, 2007/03/19
- Re: [Discuss-gnuradio] window sizing issue, ematlis, 2007/03/16
- Re: [Discuss-gnuradio] window sizing issue, ematlis, 2007/03/19