[Qt-interest] Using Qt in a shared library

[Murphy, Sean M.]

> You can't put the gui-stuff in something different than the main-
> thread. See the Qt docs for the reason;-)

I understand this statement in general, but usually it's referring to us
creating an entire Qt multi-threaded application, where we use QThreads
to create QObjects outside of the main thread.  But when what I'm
creating is a plug-in to another (non-Qt) application, what thread is
the main thread?  For all I know my plug-in could be a thread of a
thread of a thread of wherever their main() lives.  

I *believe* that as far as Qt is concerned, that the requirement for
mixing threads and GUIs is that GUI stuff has to have the same thread
affinity as the QApplication object.  But I think that would allow my
plug-in to spawn a new thread (not using Qt at this point, so maybe pure
pthreads at this point), and then creating all my Qt objects in that
explicitly spawned thread.  It seems that if my QApplication object and
all my Qt objects live in that new thread, I wouldn't be making GUI
calls across threads, I'd only have to populate non-Qt data structures
between my Qt thread and the thread their application is calling
Callback() from.

I haven't tried this at all, and since I have a working, but sluggish
solution, I might not ever attempt it.  I can't really find much
documentation that talks about this Qt plug-in in a non-Qt application
case.

> But maybe you can make the callback function check how much time
passed
> for the run of processEvents and have it repeat processEvents() as
long
> as the set interval isn't exceeded. That way you get more event-
> processing then just the 2-4Hz. Maybe you have to delay the loop a bit
> with a sleep...

I think I'm missing something here, or I didn't explain clearly enough.
It appears that the sluggishness that I'm seeing is because Callback()
isn't being called frequently enough, and Qt only gets a chance to spin
its event loop once per Callback().  So when the user clicks on a Qt
button, it might be between 0.25 and 0.5 seconds before Callback() is
called, which then calls qApp->processEvents(), and the Qt loop spins.
But there isn't anything I can do to control how often they call
Callback().  Remember, Callback() is called by their application, not
called by me.  

>From testing I tried before, when I was trying to exec() my dialog, it
appears that Callback() is a blocking call - their GUI loop doesn't spin
until I return from Callback().  So I need to get out of Callback() as
fast as possible otherwise to the user, it will appear that the main
application is sluggish, which in this case is far worse than if just my
dialog appears sluggish.  The real application is similar in nature to
Google Earth where the user can pan around the globe, zooming in/out,
etc.  So it's far worse if the panning of the world looks sluggish as
opposed to there being some latency between clicking my button and the
resulting action.

I appreciate any tips though!
Sean