# wxPython 3.0 breaks wxGUI

**URL:** <https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358>\
**Category:** GNU Radio\
**Created:** [June 13, 2014, 2:21am UTC](https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358 "2014-06-13T02:21:11Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\
**Post date:** [June 13, 2014, 2:21am UTC](https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358/1 "2014-06-13T02:21:11Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Jookia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/5daacb/32.png) [@Jookia](https://www.ruby-forum.com/u/Jookia)\
**Post date:** [June 13, 2014, 4:44am UTC](https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358/2 "2014-06-13T04:44:45Z")

</div>

On Thu, Jun 12, 2014 at 8:19 PM, Jookia [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![Jookia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/5daacb/32.png) [@Jookia](https://www.ruby-forum.com/u/Jookia)\
**Post date:** [June 13, 2014, 4:54am UTC](https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358/3 "2014-06-13T04:54:15Z")

</div>

On 06/12/2014 10:43 PM, Tom R. 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.

---

<div class="post-metadata">

**Author:** ![Jookia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/5daacb/32.png) [@Jookia](https://www.ruby-forum.com/u/Jookia)\
**Post date:** [June 15, 2014, 10:39pm UTC](https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358/4 "2014-06-15T22:39:01Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Jookia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/5daacb/32.png) [@Jookia](https://www.ruby-forum.com/u/Jookia)\
**Post date:** [June 19, 2014, 4:33pm UTC](https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358/5 "2014-06-19T16:33:43Z")

</div>

On 13/06/14 12:43, Tom R. 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.

---

<div class="post-metadata">

**Author:** ![Jookia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/5daacb/32.png) [@Jookia](https://www.ruby-forum.com/u/Jookia)\
**Post date:** [June 17, 2014, 6:18pm UTC](https://www.ruby-forum.com/t/wxpython-3-0-breaks-wxgui/230358/6 "2014-06-17T18:18:04Z")

</div>

On Sun, Jun 15, 2014 at 4:36 PM, Iain Young, G7III [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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