A few questions regarding QT GUI development

GNU Radio
1

Greetings all,

     I recently began using gnuradio and GRC with a pair of USRPs.

It’s my understanding that plans are underway to ultimately remove WX in
v3.9 as a GUI option from gnuradio, and replace it with QT. It’s also my
understanding that QT GUI development is underway in future versions of
gnuradio. I’m interested in attempting to help develop for gnuradio and
have forked a copy of the source from github.

     With that in mind, I have a few questions:

 1. Who is involved with QT GUI development for gnuradio?
 2. What future improvements, especially functionality related, are
    planned for gnuradio QT? All I have been able to find in the
    3.8.0 roadmap is that grc will "introduce a QT version of GRC"
    (what does that mean?) and that gr-qtgui will be switching
    examples to use gr-qtgui instead of gr-wxgui. Functionality I'm
    most interested in includes X/Y mode for the QT GUI Time Sink
    and the ability to pause the output of the Time, Frequency, and
    Waterfall sinks (as is available via the "Stop" button in the WX
    counterparts.
 3. In looking over the WX and QT GUI options, I personally prefer
    the layout and functionality of the WX GUI components
    (specifically, the instrumentation options). Are there any plans
    to attempt to replicate the layout and options of the WX
    components? (Perhaps the old WX layout style and functionality
    are being abandoned for good reason; if that's the case, if
    anybody could clarify that for me or point me in the right
    direction I would be most appreciative.)

Thanks everyone, and I look forward to hearing from you!

–George

2

Hi George,

It’s also my understanding that QT GUI development is underway in
future versions of gnuradio.
I’d say it’s pretty usable and stable in current versions of gnuradio.
It’s also my understanding that QT GUI development is underway in
future versions of gnuradio.
Have a git blame one the gr-qtgui subdirectory. You’ll mainly find Tom
as contributor, but of course, a lot of people contribute features, new
sinks, bugfixes etc.
So, I’d say, it’s an overall community effort.
will “introduce a QT version of GRC” (what does that mean?)
GRC (GNU Radio Companion) is, to date, a GTK application, and there’s
work going on to “port it” to Qt (I’d rather say, there’s someone who’s
rewriting the GUI part completely, but in effect, it’s a port).

gr-qtgui will be switching examples to use gr-qtgui instead of gr-wxgui
Um, I don’t understand that, either, but it means that in the future,
examples will be based on Qt GUI (rather than WX or QT, depending on
when/who wrote them).

Functionality I’m most interested in includes X/Y mode for the QT GUI
Time Sink and the ability to pause the output of the Time, Frequency,
and Waterfall sinks (as is available via the “Stop” button in the WX
counterparts.
Have you tried middle mouse button, for example on the waterfall sink?

All in all, the Qt widgets are easier to integrate into “real world”
applications, and they are far more easily customized – a CSS might be
all you need.

Greetings,
Marcus

3

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

4

On 24.03.2015 09:04, George H. wrote:

Greetings all,

     I recently began using gnuradio and GRC with a pair of USRPs.

It’s my understanding that plans are underway to ultimately remove WX in
v3.9 as a GUI option from gnuradio, and replace it with QT. It’s also my
understanding that QT GUI development is underway in future versions of
gnuradio. I’m interested in attempting to help develop for gnuradio and
have forked a copy of the source from github.

Whoooo! We are really very happy about new developers, especially on
the GUI side.

     With that in mind, I have a few questions:

 1. Who is involved with QT GUI development for gnuradio?

Tom is the main guy for this, and he’ll probably chip in.

 2. What future improvements, especially functionality related, are
    planned for gnuradio QT? All I have been able to find in the
    3.8.0 roadmap is that grc will "introduce a QT version of GRC"
    (what does that mean?) and that gr-qtgui will be switching
    examples to use gr-qtgui instead of gr-wxgui. Functionality I'm
    most interested in includes X/Y mode for the QT GUI Time Sink
    and the ability to pause the output of the Time, Frequency, and
    Waterfall sinks (as is available via the "Stop" button in the WX
    counterparts.

Before you rush ahead, X/Y mode is already available through the
‘constellation’ sink. But that’s not to say we can’t change the time
sink. Particularly for people who are used to it.

Pause is already in QT – check out the menu.

 3. In looking over the WX and QT GUI options, I personally prefer
    the layout and functionality of the WX GUI components
    (specifically, the instrumentation options). Are there any plans
    to attempt to replicate the layout and options of the WX
    components? (Perhaps the old WX layout style and functionality
    are being abandoned for good reason; if that's the case, if
    anybody could clarify that for me or point me in the right
    direction I would be most appreciative.)

Yes, but don’t want it to be permanent. Ideal woulde be a sidebar with
instrumentation buttons that is collapsible, or hidable or something
like that.

There’s a couple of things we’d like to add to the QT widgets, let me
have a look if I can find that list.

Cheers,
M

5

On Tue, Mar 24, 2015 at 10:00 AM, Richard B. [email protected]
wrote:

Is there a plan to improve the layout customizability beyond the GUI
Hints? I think the gui hints are counter-intuitive and don’t provide a lot
of control.

Rich

I don’t find them that counter-intuitive. The (row, col, rowspan,
colspan)
is a fairly often used concept in grid layouts. Still, I don’t disagree
that we can make this better and offer more flexibility. Do you specific
suggestions that we could discuss?

Tom

6

Is there a plan to improve the layout customizability beyond the GUI
Hints?
I think the gui hints are counter-intuitive and don’t provide a lot of
control.

Rich

On Tue, Mar 24, 2015 at 9:57 AM, Martin B. [email protected]

7

Yes. I’m glad you asked :-).

The counter-intuitiveness of it for me, comes from rowspan and colspan.
I
might make an incorrect statement here, so please correct me if I do.

  1. I think rowspan and colspan should give you control over the height
    and
    width of the widget. Instead, it defines how many columns or rows the
    widget is allowed to spill into. Without having control over column and
    row
    width, you don’t have control over widget height and width.

  2. Allow control of grid positions height/width. This would allow one
    widget to dominate the screen and other lesser widgets to be sprinkled
    around it.

  3. If you don’t add any GUI Hints, Have the widgets auto-fit to your
    monitors screen size so that you don’t have to scroll up and down the
    window to see plots.

  4. When using the GUI Tabs feature (which I love), don’t connect one
    tabs
    grid layout to the other tabs. Let them have independent sizing. I’m
    struggling with this now.

Those are the main ones I can think of.

v/r,
Rich

8

Thanks, Rich, see below for some comments.

On Tue, Mar 24, 2015 at 11:00 AM, Richard B. [email protected]
wrote:

Yes. I’m glad you asked :-).

The counter-intuitiveness of it for me, comes from rowspan and colspan. I
might make an incorrect statement here, so please correct me if I do.

  1. I think rowspan and colspan should give you control over the height and
    width of the widget. Instead, it defines how many columns or rows the
    widget is allowed to spill into. Without having control over column and row
    width, you don’t have control over widget height and width.

The rowspan and colspan come directly from how QT handles this stuff
itself. It’s a grid layout, and so by default, all elements in the grid
are
given equal slices of the window. The span is how many elements the
widget
will span.

There are (read: should be) ways to control sizing, though, but I’m not
familiar enough to know exactly how to do this off the top of my head.
In
fact, in my playing with adding the instrumentation panel that I
mentioned,
I’m needing to look into this exact issue. What we might be able to do
is
provide another tab for more properties like max/min height and width.
Because yeah, I agree that it’d be nice to have this kind of control,
even
though I think the basic (row, col, rowspan, colspan) will probably
stick
around.

  1. Allow control of grid positions height/width. This would allow one
    widget to dominate the screen and other lesser widgets to be sprinkled
    around it.

Sure. I think this falls into the issues in 1 that can be handled at the
same time.

  1. If you don’t add any GUI Hints, Have the widgets auto-fit to your
    monitors screen size so that you don’t have to scroll up and down the
    window to see plots.

I’m not sure if you can actually do that. It’d be great if someone more
knowledgeable about GUI and QT could weigh in here. But figuring out the
size of the screen isn’t something that I think we can know. And even if
we
do, how to go about properly scaling things might work better for some
than
others. Anyways, I think this is a nice thought, but I’m not sure how
doable and/or practical it is.

  1. When using the GUI Tabs feature (which I love), don’t connect one tabs
    grid layout to the other tabs. Let them have independent sizing. I’m
    struggling with this now.

Indeed. I feel like this is just default QT behavior. It’ll again take
some
time and expertise to fix this.

Those are the main ones I can think of.

v/r,
Rich

Thanks again.

Tom