discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Discuss-gnuradio] gr_qtgui, SWIG. QT Signals and such


From: Mike Cornelius
Subject: RE: [Discuss-gnuradio] gr_qtgui, SWIG. QT Signals and such
Date: Tue, 4 Jan 2011 20:00:42 +1100


On Tue, Jan 4, 2011 at 2:42 AM, Tom Rondeau <address@hidden> wrote:
>
> On Mon, Jan 3, 2011 at 2:53 AM, Mike Cornelius <address@hidden> 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.

Thanks Tom :)

>
> > 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.
>

Ahhh, I'd had my head in the C++ side of things and completely forgotten
about 'sip.wrapinstance' 
My initial though had been to replace/augment SWIG in the build system with
SIP, maybe that's not necessary (which would be good)

> >
> > 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.
>

Agreed, the UI form is definitely useful, 2 interfaces makes sense I think.


> > - 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.
>

So far the work I've done has been pretty rough proof of concept stuff just
to test the waters so I've not yet added interfaces for all the existing
features however that's certainly the plan.

> > - 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?

The CF marker is a vertical line in the centre of the spectrum plot window,
it's a handy visual tuning aid (like Marker->CF on an a spectrum analyser).

Presently the zoom function in gr_qtgui works as 'click - drag - click' I
changed it to 'button down - drag - button up'


>
> > - 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.
>

Thanks, Much appreciated !

> > See http://yfrog.com/f/h8a0xp 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?
>

I don't presently however I'll set something up on the weekend when I have a
few more spare moments.

> Thanks!
> Tom





reply via email to

[Prev in Thread] Current Thread [Next in Thread]