Re: [Discuss-gnuradio] Creating GUI widgets OOT using C++

[Sylvain Munaut]

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 <address@hidden> 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.