On Wed, 31 Mar 2004 13:48:17, "Roberto Alsina" <[EMAIL PROTECTED]> wrote:
> A couple of days ago, I posted my PyBrowser class > (http://www.pycs.net/lateral/stories/17.html) in an answer to a question. > > And was told it segfaults. So I tried it. And it does. Here's the fix: > > If you comment the qApp.processEvents() in fetchURL() it will not segfault. I suspect I know the reason for this, but maybe Phil has a better understanding of the mechanisms involved. See below. > However, that means you get no progress reports whatsoever. > > I am clueless on how to make both things work. In fact, I don't see why a > processEvents there causes a segfault in QTextCursor or some other bizarre > innard of QTextBrowser :-P I think that QMimeSourceFactory.data is really supposed to return data synchronously, without doing things like emitting signals or getting the qApp to process events. I'm actually surprised that the PYSIGNALs are delivered to the printit function before the QMimeSourceFactory.data method returns, but maybe PyQt adds a layer of communication above the normal application layer. Anyway, if you do process events from within that method, it could just be luck that the browser appears to work most of the time. There's probably a race condition where QTextBrowser could receive an event while still waiting for data to be returned, and this leads to unexpected behaviour; i.e. a segfault. Ideally, you'd want to collect all the document information (images and things), cache them locally, and use the QMimeSourceFactory to provide them to the QTextBrowser as required. KHTML handles this sort of thing quite conveniently, but my equivalent example hasn't worked properly since PyKDE 3.7. :-( I'll try it again when I next reinstall PyQt and PyKDE. ;-) Have fun, David _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
