Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template

[Sylvain Munaut]

Hi,

> Have you solved your problem from yesterday with the OOT project
> inheriting from the QTGUI blocks?

No unfortunately. I made some progress though :
 - The QObject parent must be first in the inheritance.
 - Needed to include the Q_OBJECT macro in the class definition and
also enable the "AutoMOC" in the CMakeFile.txt
 - Return a dynamic_casted pointer to QWidget* in pyqwidget() method
rather than just "this".

Now it runs fine and just crashes on cleanup/shutdown.

Whenever a QWidget is added to a parent, the parent takes ownership of
the pointer and so it will be deleted when deleting the parent. Then
it will be deleted as part of GR, so that's the first issue.

But here I don't even seem to get to that point because the destructor
is called only once (I have a printf in it) and it still crashes ...
The Qt magic might be interfering with the SWIG magic ...


I also tried creating the QWidget subclass separately, like it's done
in the qtgui elements but I also have a problem on destruction because
there is a tight link between the two (exchanging a lot of data ..)
and they're destroyed independently by two completely different path
...
And it's also not such a nice solution because of the many
interactions needed between the two classes it'd be much better to
have one single object be a descendant of both QGLWidget and
gr_sync_block


> Basically, it should be possible (at
> least, I want it to be possible), but it's probably never been done
> before. I have tried to make sure everything's been exported from
> libgnuradio-qtgui to enable this, but I've never actually tried it.

Well in this case I'm not really extending a qtgui block, just adding
a new one that has to integrate with the 'top level' of the existing
ones.


> And obviously, any patches you needed to make to the qtgui library for
> this should go back into the main code to help this work better in the
> future.

For QT the only mod will probably be the multithread thing.
For WX on the other hand I'm still not sure how to make it work at all
and what kind of changes this would require.

But yeah, I definitely want this to work with an "out of the box" GR
and to get any required changes merged.


> As to the posix/X11 issue. We do some similar stuff elsewhere for
> different platform support, though mostly this is in the Cmake files.
> It's not out of the question what you've done. We'd have to look at it
> in the bigger picture. Your checks around it look good, though, so it
> seems harmless enough. I'm guessing that ctypes.cdll.LoadLibrary
> returns None if libX11.so isn't found?

Actually I though so, but under further checks it throws an OSError
exception so it would probably need to be wrapped in try catch.

Cheers,

    Sylvain