[Libreoffice] Solving an introduced runtime dependency on unreleased Qt version (KDE4 vcl backend)

[Lubos Lunak]

 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
 l.lunak at suse.cz