On Mon, Jan 3, 2011 at 2:53 AM, Mike C. [email protected] wrote:
Hi All,
I’ve been playing around with gr_qtgui and adding a few ‘enhancements’ to
suit my application, in doing so I’ve come to a bit of sticking point and
I’m looking for some advice on how to proceed, my QT and SWIG experience are
limited so I’m wary of doing things ‘the hard way’ unnecessarily.
Mike,
Great work so far! I’ll try to work with you to handle these things.
One of the things I’d like to add is support for QT Signals from my derived
‘gr_qtgui2’ back to Python, in particular I’d like to be able to double
click in the gr_qtgui plot area and receive a QT signal in my Python app.
I use sip to return a QtGui object from the C++ world. I haven’t
experimented with what you are asking for, but I hope it’s not
unreasonable. We’d have to play with what the object returned by
sip.wrapinstance is actually capable of doing. That is, can we connect
a signal to it? This is something I’ve been wanting to have, too, so
that you could have a wideband spectrum view and click on a signal to
isolate and start processing it.
Questions:-
1 - It appears to me that SWIG does not support QT signals/slots, can anyone
confirm if that’s correct?
Yes, I don’t think we’ll be doing the signal/slots interfacing through
SWIG.
2 - If so then I suppose I need to convert my ‘gr_qtgui2’ over to use SIP ?
or is there an easier way?
As I said above, because I return a Python QWidget object and that do
the sip.wrapinstance on it to get a PyQt QWidget object, we might have
luck working through this interface.
It’d be best if we can handle everything in the C++ world and connect
it to Python either through SWIG or, more likely, the SIP interface
object. That way, anything we develop for “talking” to the QT window
can be done in either a full C++ app or a Python app.
In case anyone’s interested I’ve made the following ‘enhancements’ so far:-
- Created a copy of gr_gtgui imaginatively called gr_qtgui2 which ‘builds
out of tree’ as a custom block.
- Removed the QT UI form so that the widget consists of just the plot area
and labels without the tabs and controls, this allows the widget to resize
nicely within the parent form and makes it more practical to have more than
1 gr_qtgui2 plot displayed simultaneously.
That’s perfect. I agree with how you’ve done that. I think all of the
supporting interfaces (like turning on averaging, max/min hold, etc.)
be made function calls so that they can be built up and used by the
user in whatever context you might want.
I would want to keep the current UI stuff available, though, since it
provides a nice out-of-the-box control for looking at the signals. I’d
have to see how you split out the code, but hopefully we could have
two interfaces: the raw interface you’ve created and the full one
that’s in there currently.
- Added interfaces to set the BG and FG colour
Cool.
- Added a ‘use_rf_frequencies’ interface
Good. This is one of those interfaces that I was just talking about.
Any of the controls in the UI should be made available through
function calls to the interface.
- Added a center frequency marker and interface
- Changed zoomer to use drag select rather than click select
I’m not sure what you mean by this. Probably GUI lingo that I’m not
familiar with. Could you explain?
- Added y axis (amplitude) magnification on mouse wheel
That’s cool.
- Added support in the plot area for catching double clicks and emitting a
signal (which I can’t work out how to receive in Python)
I’ll try to help you look into this.
See ImageShack - Best place for all of your image hosting and image sharing needs for an idea of where I’m heading with this.
Any advice would be greatly appreciated.
Mike VK2XMC
Could you let me know if you have this code hosted anywhere? Is there
a public github (or similar) repo that I could pull from?
Thanks!
Tom
