There are several reports of the wx version of the gnuradio gui not
starting with 3.0 and later wxpython. I believe
http://trac.wxwidgets.org/ticket/16034
confirms that no upstream fix is planned.
I suggest a simple and very ugly work-around:
in /usr/lib/python2.7/site-packages/gnuradio/grc/python/flow_graph.tmpl
, after
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
insert
self.Start(start=False)
This seems to work - it should have the necessary graphical elements
ready before the gui blocks are initialised. start=False prevents the
thread being started, a later call to Run() has start=True, and this
starts the thread.
(I have the python2-opengl library installed, and this fix works for GNU
Radio Companion 3.7.6)
–David
G8SQH
[email protected]
I haven’t seen a reply to this posting, so you’re getting my “Mac OS X /
MacPorts”-centric view.
MacPorts has been using WX >= 3.0 for quite a while now; currently at
3.0.2. I’ve done extensive testing with version 3.0 of WX and GNU Radio,
and found nothing incompatible that wasn’t already an issue (if there
were any; I no longer remember; I check regularly for basic
functionality for GNU Radio-provided WX widgets and stuff).
The above said: This is WX installed by MacPorts, and we MacPorts
developers often make changes to ports to correct functionality on Mac
OS X … we try to report upstream, and sometimes the project devs use
our patches, sometimes they fix the issues themselves, and sometimes
they fight or ignore us since we’re working on Mac OS X. Thus, it’s
entirely possible that WX for Linux has this issue, and that it’s been
patched inside MacPorts. Or, it might be that it’s just not an issue on
Mac OS X.
So … I’ll let others decide what to do here; my WX 3.0.2 install works
nicely with GNU Radio 
Can others verify the reported issue? - MLD