[Qt-interest] Using Qt in a shared library

[Murphy, Sean M.]

> On 07.05.09 11:11:41, Murphy, Sean M. wrote:
> > I'm trying to write a plug-in for a non-Qt application and am having
> > some event loop issues.  The non-Qt application that I'm writing for
has
> > PC and Linux versions, and the plug-in I'm writing performs the same
> > basic functionality as applications I've already written using Qt,
so
> > I've got all these nice (working) Qt classes ready to go, so I have
a
> > strong desire to write my plug-in using Qt.
> >
> > To create the plug-in, I inherit from their base plug-in class, and
> > reimplement 3 virtual functions:
> > Start()
> > Callback()
> > Close()
> >
> > Start() and Close() are what my plug-in needs to do at load and
unload,
> > and Callback() is called by the application "several times per
second"
> > and it's where I need to do all my updates.
> >
> > I've got a working version for the PC, but I'm not entirely sure how
it
> > works.  I create a new instance of my main class, which inherits
from
> > QDialog, and connect all my signals and slots up (buttons on the
dialog,
> > networking stuff in a QTcpSocket object, etc.), in the Start()
function.
> > Then in Callback() I just call show() on my dialog.  Originally I
tried
> > calling exec(), but then the event loop never gets passed back to
the
> > application - so my GUI works perfectly, but the main application is
> > locked up.  ***So in my working version, at no time do I call exec()
on
> > anything*** but yet it works fine on Windows.
> >
> > So then I tried to build the Linux version of my plug-in.  The
> > application is able to load it fine, but I don't appear to get any
> > events to fire in the Qt section of my code.  If I switch my show()
call
> > to an exec() call, my dialog appears and works correctly, but the
main
> > application is locked up.
> 
> Hmm, this sounds as if you should call show() already in Start() and
in
> Callback() simply call qApp->processEvents() so the Qt event loop
processes
> the events. That "emulates" what exec() does, but doesn't block longer
> than one run through the loop needs (i.e. it processes all events in
the
> queue and then returns, instead of waiting for more events to get into
the
> queue like exec() does).

Yep, works pretty well!  The only downside is that the Qt GUI is a bit
sluggish.  It appears that Callback() gets called at about 2-4 Hz, so
there is a noticeable lag between typing/clicking and the Qt repaint,
but I don't think there's really too much I can do about it - unless I
try putting all the Qt stuff in a separate thread.

Ironically, I had actually put the qApp->processEvents() line in last
night, but didn't get a chance to test it.  I tried to test, but I was
connected to the Linux box over Exceed which I can't seem to get to pass
OpenGL calls back to my Windows box.  Since the real application uses
OpenGL, it refused to start and exited with a "requested OpenGL
extension not available" error.  At that point, I had been beating my
head against this problem for a couple of hours and decided to call it a
day.  Then when I came in this morning, I wrote the note to qt-interest,
forgetting that I had a version that I hadn't tested yet!

Thanks!
Sean