Re: [Discuss-gnuradio] grc and wxpython >=3.0

[Michael Dickens]

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

On Wed, Feb 4, 2015, at 12:45 PM, address@hidden wrote:
> 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)