(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.
on 2014-06-13 02:21
on 2014-06-13 04:44
On Thu, Jun 12, 2014 at 8:19 PM, Jookia <email@example.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
on 2014-06-13 04:54
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.
on 2014-06-15 22:39
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
on 2014-06-17 18:18
On Sun, Jun 15, 2014 at 4:36 PM, Iain Young, G7III <firstname.lastname@example.org> 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
on 2014-06-19 16:33
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.