This might be also also for packagers, do we have a place where to reach them?
Since 3.4 at least, when run with KDE4 integration, LO kind of happens to have a runtime dependency on a yet unreleased Qt version, otherwise LO will abort during some reasonably commonplace operations, such as drag&drop of cells in Calc (https://bugs.freedesktop.org/show_bug.cgi?id=40298). The primary reason for this is that historically Qt used to be a toolkit for single-threaded use, building more of thread-safety over the time, and the widgets are not supposed to be used from more threads even by now, AFAIK. That doesn't quite fit with LO, which occassionally will do UI stuff even from other threads. In a nutshell, drag&drop is handled in LO by a separate thread and can result in some UI changes, such as drawing a progressbar. I some time ago noticed the progressbar wasn't themed properly by the KDE4 backend (possibly for this reason) and fixed that. But the QPixmap class actually checks whether it's used from the main thread or not and that's what triggers the bug linked to above. Now, the catch is that I of course noticed the bugreport and fixed it, but I use a development snapshot of Qt (to-become 4.8), which does not work with the latest 4.7.4 release or older. We've already made LO releases with this problem and e.g. the latest openSUSE release has this problem too. The only actual problem appears to be the check in QPixmap, as the feature of the 4.8 snapshot that enabled me to avoid the problem pretty much only gives a way to avoid the check, as long as XInitThreads() has been called. Qt4.8 documentation still does not mark the class as reentrant or thread-safe, but given the change I don't see why it shouldn't be reentrant. So my fix for openSUSE will be to backport the Qt change to the shipped Qt package. I'm not sure what to do about upstream LO though. The ideal solution is for everybody to get an updated Qt package, but I don't know what packagers think about that. I could also change the progressbar integration fix to somehow detect when it is safe to use, but that may be just papering the problem over, as I cannot guarantee there are no other ways to trigger the Qt check. I also don't know how exactly thread safety is supposed to work in LO, so I cannot quite guess. I've been told that VCL only works with Solar mutex grabbed, which means that Qt usage from it should be safe, if the way to avoid the QPixmap check is avoided. But there are other UI elements in LO, such as the fpicker, which AFAIK are not triggered using VCL and I don't know how that is supposed to work. What do you suggest to do about it? PS: I've attached a backport of the Qt change to https://bugs.freedesktop.org/show_bug.cgi?id=40298 . -- Lubos Lunak [email protected] _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
