[Qt-interest] Using Qt in a shared library

[Arnold Krille]

Hi,

On Thursday 07 May 2009 22:41:28 Murphy, Sean M. wrote:
> > 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.

Note that QObject != Gui. Of course you can QObjects in any thread you like! 
There will only be problems if you make gui-calls in a different thread then 
the one that instantiated the connection to X. At least on linux as far as I 
know.

> 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.

Could be right.

I actually only do Qt-only:-)

> > 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().

Let me explain. Currently your Callback() is something like this:
void Callback() {
  qApp->processEvents();
}

But this only gets called every 0.5 seconds worst case. So you write a 
function like:
void Callback() {
 QTime t;
 t.start;
 while( t.elapsed() < 300 )
  qApp->processEvents();
}

> >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.

Which rules out my idea.

If you are right about Qt-gui things beeing possible from whatever thread that 
created the X-connection, you could simply ignore the whole Callback()-thing 
and start your own gui-thread in the init() function. This would give you an 
independant event-loop with graphics.
But it could be that this isn't working on linux when one app creates two 
connections with X from different threads...

Have fun,

Arnold (-> bed)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090507/f5a6eabb/attachment.bin