Forum: GNU Radio wxPython 3.0 breaks wxGUI

390226db48db5c3c4f9bd4acb4537c5d?d=identicon&s=25 Jookia (Guest)
on 2014-06-13 02:21
(Received via mailing list)
(Apologies if this is posted twice, I subscribed as it didn't seem to be
show up on the archives.)

Hey there,

Arch Linux uses wxPython 3.0 which throws assertions that I haven't had
the patience to track down, to do with m_window not being established:

Traceback (most recent call last):
  File "./top_block.py", line 87, in <module>
    tb = top_block()
  File "./top_block.py", line 43, in __init__
    y_axis_label="Counts",
  File
"/usr/lib/python2.7/site-packages/gnuradio/wxgui/scopesink_nongl.py",
line 76, in __init__
    v_scale, t_scale, self.guts, title), parent)
  File
"/usr/lib/python2.7/site-packages/gnuradio/wxgui/scopesink_nongl.py",
line 243, in __init__
    self.graph = graph_window(info, self, -1)
  File
"/usr/lib/python2.7/site-packages/gnuradio/wxgui/scopesink_nongl.py",
line 468, in __init__
    EVT_DATA_EVENT(self, self.format_data)
  File
"/usr/lib/python2.7/site-packages/gnuradio/wxgui/scopesink_nongl.py",
line 142, in EVT_DATA_EVENT
    win.Connect(-1, -1, wxDATA_EVENT, func)
  File "/usr/lib/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", line
4182, in Connect
    return _core_.EvtHandler_Connect(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "m_window" failed at
./src/gtk/dcclient.cpp(2041) in DoGetSize(): GetSize() doesn't work
without window

It seems to be caused by this block of code in
gr-wxgui/python/wxgui/plot.py:

        # OnSize called to make sure the buffer is initialized.
        # This might result in OnSize getting called twice on some
        # platforms at initialization, but little harm done.
        self.OnSize(None) # sets the initial size based on client size
                          # UNCONDITIONAL, needed to create self._Buffer

    def OnSize(self,event):
        # The Buffer init is done here, to make sure the buffer is
always
        # the same size as the Window
        Size  = self.GetClientSize()

I'm uncertain who's at fault, upstream or GNU Radio. wxWidgets 3.0.0's
plot.py is different code-wise so this may be an actual problem that's
been hidden by not having assertions, I'm guessing calling . There's a
couple of ways to fix it:

1. Move to a new plot.py and backport some functions to make it work. I
did some vague copy pasting and managed to get an output that worked. It
seems the specific stuff seems to be just UseScopeTicks, which is only
used by scopesink_nongl, maybe some refactoring could help fix this?

2. Commenting out the "self.OnSize(None)", call entirely seems to work
so it might be that OnSize is called properly nowadays. However the
upstream plot.py doesn't indicate this.

Anyways, that's about it. Things are broken on Arch Linux for now, and
for future distributions that move to wxPython 3.

Cheers,
Jookia.
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2014-06-13 04:44
(Received via mailing list)
On Thu, Jun 12, 2014 at 8:19 PM, Jookia <166291@gmail.com> wrote:

>     tb = top_block()
>   File
> wx._core.PyAssertionError: C++ assertion "m_window" failed at
>                           # UNCONDITIONAL, needed to create self._Buffer
>
> for future distributions that move to wxPython 3.
>
> Cheers,
> Jookia.
>

Jookia,

Thanks. this was discovered a couple of days ago. We don't really have
anyone to fix it right now, so if you can complete your solution(s) you
mentioned above and send us a patch, that would be fantastic.

In one sense, this is a low priority because we are moving away from
using
the wx sinks in favor of the qt sinks. Still, for now, most of our
examples
are base on wx, so we will need this to work for a little bit longer.

Tom
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2014-06-13 04:54
(Received via mailing list)
On 06/12/2014 10:43 PM, Tom Rondeau wrote:
>
>
> In one sense, this is a low priority because we are moving away from
> using the wx sinks in favor of the qt sinks. Still, for now, most of
> our examples are base on wx, so we will need this to work for a little
> bit longer.
>
> Tom
>
Tom, it's not just the examples.  It's a significant base of "3rd party"
applications.   If you make WX go away without having some kind of
   uber-smooth transition plan, then the bad taste left by the 3.6 to
3.7 transition will be remembered, and it won't be pretty.
4a41bed29f715721ff51ab969558cf9d?d=identicon&s=25 Iain Young, G7III (Guest)
on 2014-06-15 22:39
(Received via mailing list)
Hi Folks,

Sorry to be late with my two penneth, but I am still in catch up mode
from vacation.

On 13/06/14 03:52, Marcus D. Leech wrote:
> Tom, it's not just the examples.  It's a significant base of "3rd party"
> applications.   If you make WX go away without having some kind of
>    uber-smooth transition plan, then the bad taste left by the 3.6 to
> 3.7 transition will be remembered, and it won't be pretty.

I have some concerns of my own here. I'll admit that most of the QT GUI
sinks look "cuter", (and in some cases work better). I do use both,
depending on what I need.

The one where the WX GUI wins for my use is the (Non GL) version of the
WX Waterfall vs the QT Waterfall. It's raw simplicity to show me what I
need (often did I get the filters right...)

Even playing with the QT Waterfall's settings, autoscale, bin size etc,
it never quite seems as "easy" to spot signals in it, esp weaker ones.
It's probably just levels that I'm feeding it, but the WX Waterfall
works better in this regard for me.

If there would be a way (within GRC) to turn off all the decoration
(Time, Intensity, Frequency Axis labels etc), so we just have the raw
waterfall, I'd love that, as things like the QT Time Sink work way
better than the WX equivalent.

Also, the QT version seems limited to auto scaling or not. On the WX
version I can set my own Dynamic Range, Reference Level, and Reference
Scales should I decide to.

BTW I think I found a bug. When you first fire the QT Waterfall GUI up,
and select "Multi-Colour" colour map, it doesn't work. Select another
colour map, and then select the multi-colour map, and it's fine.


Iain
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2014-06-17 18:18
(Received via mailing list)
On Sun, Jun 15, 2014 at 4:36 PM, Iain Young, G7III <g7iii@g7iii.net>
wrote:

>>>
>>    uber-smooth transition plan, then the bad taste left by the 3.6 to
>
> Also, the QT version seems limited to auto scaling or not. On the WX
> version I can set my own Dynamic Range, Reference Level, and Reference
> Scales should I decide to.
>
> BTW I think I found a bug. When you first fire the QT Waterfall GUI up,
> and select "Multi-Colour" colour map, it doesn't work. Select another
> colour map, and then select the multi-colour map, and it's fine.
>
>
> Iain


Thanks for the feedback.

I can see a use for turning off the decorations in the waterfall plot.
I'd
hope that it'd be a simple function call to just alter the QwtPlot
attributes for these things. Then, it'd simply be another menu item to
toggle it on/off like the other menu features (like turning the grid
on/off).

And I agree about the dynamic range settings. The qtsink itself allows
you
to set the min/max values. We really should make those settings
available
to the user in the waterfall sink, too. I believe the accessor to do
that
is available in the class and needs to be exposed in GRC and in the
drop-down menu settings.

As for the multi-color map, that's the default map. So clicking it won't
change anything since you're just selecting the current setting. If you
go
to the 'config' tab of the properties box, you should be able to set
different color maps as the defaults.

Tom
390226db48db5c3c4f9bd4acb4537c5d?d=identicon&s=25 Jookia (Guest)
on 2014-06-19 16:33
(Received via mailing list)
Attachment: wx-newplot.patch (100 KB)
On 13/06/14 12:43, Tom Rondeau wrote:
>
> Tom
>

Hey,

I've attached a patch (I hope attachments show up, otherwise I can send
it to you directly?) that uses the new plot.py with some GNU Radio
specific stuff brought back. It's pretty much a rewrite, but if you want
specific changes you can always diff against the wxWidgets plot.py
mentioned in the commit that I noted.

It's not fit to merge unless you want to break wxWidgets 2.8
compatibility, and I can't figure out why. For some reason the scope
sink's size is tiny, while the other plots work. I want to say this is
because the scope sink inherits the plot directly and inheritance is
what seems to be the breakage between wxWidgets 2.8 and wxWidgets 3.

Maybe it'd be worth just removing or deprecating the non-GL plots? If
not I suppose the new plot.py could be only used in wxWidgets 3 cases.
Or the one line OnSize thing could be removed.

Jookia.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.