Richard Heck wrote: > I don't know exactly what's going on here, but I think I can solve the > problem. I also think it's a QT bug, not ours. > > At first I thought there must be some kind of event loop. But adding > some lyxerr's to GuiApplication::notify() showed me that it wasn't: > You'd get a paint event for the slider, but then that would be the last > event you'd see. Interrupting LyX doing whatever it was doing showed > that it was basically stuck in that painting routine, and it always > seemed to be in qt_x11_get_brush_gc. I think what's happening MIGHT be > that this returns null if the widget paintEngine isn't active, which > maybe it isn't if the slider isn't enabled. So, anyway, I figured I'd > try just enabling the slider, and that seems to do the trick. The TOC > comes up much more quickly, and I've not yet been able to get the > freeze. So, as I said, it seems like a QT bug, really. > > Leaving the slider enabled is harmless: It doesn't do anything if > there's nothing in the TOC, anyway. But if we want to prevent people > from moving it around anyway, perhaps the thing to do would be to > setFocusPolicy to Qt::NoFocus. > ...and then setting it to Qt::StrongFocus on the other branch, of course.
Abdel, do you want to decide exactly how to handle this, assuming the hack attached to the other message works? Richard -- ================================================================== Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ ================================================================== Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
