So after continuing to bang my head against a wall for WX, I decided to try my luck at Qt.
That mostly works better. However I tried having my class inherit both from gr_sync block and from QWidget and that doesn't seem to work too well. It seems that my destructor gets called : Breakpoint 2, 0x00007fffe07e17c0 in gr::guitest::qt_impl::~qt_impl() () from /opt/gnuradio-3.7/lib64/libgnuradio-guitest.so (gdb) bt #0 0x00007fffe07e17c0 in gr::guitest::qt_impl::~qt_impl() () from /opt/gnuradio-3.7/lib64/libgnuradio-guitest.so #1 0x00007fffec017332 in ?? () from /usr/lib64/python2.7/site-packages/PyQt4/QtDesigner.so #2 0x00007ffff51866fb in ?? () from /usr/lib64/python2.7/site-packages/sip.so #3 0x00007ffff518a077 in ?? () from /usr/lib64/python2.7/site-packages/sip.so #4 0x00007ffff518af73 in ?? () from /usr/lib64/python2.7/site-packages/sip.so #5 0x00007ffff7afa1ce in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #6 0x00007ffff7afb955 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #7 0x00007ffff7a8724c in ?? () from /usr/lib64/libpython2.7.so.1.0 #8 0x00007ffff7a61413 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #9 0x00007ffff7a7020f in ?? () from /usr/lib64/libpython2.7.so.1.0 #10 0x00007ffff7a61413 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #11 0x00007ffff7ab7d86 in ?? () from /usr/lib64/libpython2.7.so.1.0 #12 0x00007ffff7ab79e8 in ?? () from /usr/lib64/libpython2.7.so.1.0 #13 0x00007ffff7a61413 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #14 0x00007ffff7af8c4a in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #15 0x00007ffff7afb955 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #16 0x00007ffff7afba82 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0 #17 0x00007ffff7b15d1c in ?? () from /usr/lib64/libpython2.7.so.1.0 #18 0x00007ffff7b16b80 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0 #19 0x00007ffff7b1760d in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0 #20 0x00007ffff7b290ab in Py_Main () from /usr/lib64/libpython2.7.so.1.0 #21 0x00007ffff747460d in __libc_start_main () from /lib64/libc.so.6 #22 0x000000000040091d in _start () But I don't know why !?! ... Is there really no other way than to have a distinct GUI widget class and gr_sync block class and forward everything from one to the other ? Cheers, Sylvain On Tue, Sep 24, 2013 at 3:31 PM, Sylvain Munaut <246...@gmail.com> wrote: > Hi, > > I'm currently attempting to create an OOT WX widget. And I'm facing > some issue with SWIG (I think). > > The "make" method looks like this : > > wx::sptr wx::make(wxWindow* parent) > > And the GRC .xml gives as the first argument the 'top_level' (like in > other wx elements), which is of the type : > > <grc_gnuradio.wxgui.panel.Panel; proxy of <Swig Object of type > 'wxPanel *' at 0x3ab9440> > > > and wxPanel is indeed a subclass of wxWindow, however I get : > > Traceback (most recent call last): > File "./top_block.py", line 55, in <module> > tb = top_block() > File "./top_block.py", line 32, in __init__ > self.guitest_wx_0 = guitest.wx(self.GetWin()) > File > "/opt/gnuradio-3.7/lib64/python2.7/site-packages/guitest/guitest_swig.py", > line 111, in make > return _guitest_swig.wx_make(*args, **kwargs) > TypeError: in method 'wx_make', argument 1 of type 'wxWindow *' > > So my guess is that SWIG somehow needs to know where/what/how about > the wx vs wxPython relation ship ... but I have no idea how. > Everything I tried so far resulted in a bunch of errors. > For examples, trying to %import the "window.i" from > /usr/include/wx-2.8/wx/i_files/ results in a bunch of errors like : > > /usr/share/swig/2.0.9/std/std_vector.i:87: Error: Can't copy typemap > (directorout) std::vector< size_t,std::allocator< size_t > > = > std::vector< size_t,std::allocator< size_t > > &DIRECTOROUT > > So has anyone ever done something like this ? > > Even if I manage to create it, the next issue I face is the threading > model. I'm playing with OpenGL and OpenCL and essentially everything > needs to run from one single thread (which ever was used to create the > GL context), and I'm not really sure how to ensure that as a wx > widget. > > Cheers, > > Sylvain Munaut > > > PS: I'll also need to do the same for Qt as well a bit later so if you > have any example of that, feel free to share. Although given it's > already C++ in the base widgets, I hope it'll be easier. The threading > issue will be the same though, so if you have info on that, please > share. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio