Re: [Discuss-gnuradio] wxPython 3.0 breaks wxGUI
On Sun, Jun 15, 2014 at 4:36 PM, Iain Young, G7III g7...@g7iii.net wrote: 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: 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. 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 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] wxPython 3.0 breaks wxGUI
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: 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] wxPython 3.0 breaks wxGUI
(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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] wxPython 3.0 breaks wxGUI
On Thu, Jun 12, 2014 at 8:19 PM, Jookia 166...@gmail.com wrote: (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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] wxPython 3.0 breaks wxGUI
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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
