On Monday 16 August 2004 18:51, Phil Thompson wrote: > On Monday 16 August 2004 5:43 pm, Toby Dickenson wrote: > > On Monday 16 August 2004 17:09, Truls A. Tangstad wrote: > > > It's a hard pill to swallow though, since this means our application > > > will have to be infected with Qt in layers not at all related to GUI, > > > just because GUI components can register callbacks etc. in them. > > > > Indeed. We have been making the same mistake, although without the obvious > > ill effects of your example. > > > > Where does this limitation come from? The Qt threading documentation doesnt > > mention a requirement to use QThread, so I assume it comes from PyQt > > somewhere..... > > > > Is there any other way to signal an event of any kind into Qt's event loop > > from a non-QThread thread? > > Hmm - don't go rushing around changing code just yet. I may be able to > remove the limitation for SIP v4.
Im assuming this 'right' solution is non-trivial..... Is it viable to suggest an additional API in a worse-is-better style... We dont really need to be able to create python QCustomEvent subclasses in arbitrary threads. Thats nice, but not necessary. I guess we could get by with a single static function which takes a QObject receiver and integer QEvent::Type as parameters. The construction of QCustomEvent and QApplication::postEvent could all happen in C++. I wish I knew whether that would be substantially easier than the right solution, but I still havent had time to dive into sip :-( -- Toby Dickenson _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
