To reproduce: * Make sure no libreoffice instance is running * Also make sure that you are actually using the kde file dialogs * Start e.g. writer * write some text * select it * trigger "copy" (ctrl+c, context menu etc.) * press e.g. "open document" The dialog takes ages to pop up, navigating to other directories will take ages. It happens that selecting one single file takes more than one minute. Also notice that there is no high CPU usage, so looks like a locking issue.
I can exactly reproduce this with Libreoffice 4.1.4.2 on my Gentoo System.
Same here under Fedora 20, with both 4.1.4 and master (Build ID: 1a37a61be4a39079d6e9fa671d04036a56510281).
An interesting observation by firefly in the german Gentoo forums: http://forums.gentoo.org/viewtopic-p-7493666.html#7493666 If you open another application (firefox, text editor, ...) and copy some text the file dialogs start to respond quickly as usual again. firefly says it is related to the Clipboard selection type ownership.
This is a "regression" introduced by 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb to fix #69002. Currently I don't know how to fix it. I might need to implement something like 1c7d90a8f9a38b166168468bed60405ef6e26493 for clipboard polling - somehow. Without 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb I get - again - crashes with KDE4 file dialogs - mmpf. I actually wanted to implement a correct fix, but got no reply to https://bugreports.qt-project.org/browse/QTBUG-34614.3 is actually more of a workaround then a real fix. I hope to find a solution today but unfortunately I won't be able to look into this problem next week.
(In reply to comment #4) > This is a "regression" introduced by > 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb to fix #69002. Not sure, since it's reproducible even with 4.1.4 which doesn't have that commit AFAIK.
I tested the reverted patch on master. (ok I just added the m_pApplication->clipboard()->setProperty( "useEventLoopWhenWaiting", true ); line ). This did help, but reintroduces the crashes. I assumed everybody used distro (e)builds and I've heard Gentoo backported the KDE4 patches.
(In reply to comment #5) > (In reply to comment #4) > > This is a "regression" introduced by > > 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb to fix #69002. > Not sure, since it's reproducible even with 4.1.4 which doesn't have that > commit AFAIK. Gentoo LO team here. Gentoo 4.1.4 has it, was backported (only cosmetic changes needed). Maybe Fedora too?
Ok - I've pushed 380f3b4b6cbbe8e82b58ddf55e95c5005307b51f to master. Not really a fix, but it seem to make things better. I've also added a backport for 4.2 to https://gerrit.libreoffice.org/#/c/8435/. Should also apply to 4.1, if you have all the previous patches. Hint, hint: there is private/jmux/libreoffice-4-1+fixes...
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e95d5d52c84c073e1878c290031cdde6061fcc7d&h=libreoffice-4-2 fdo#74416: sleep in yield for native file picker It will be available in LibreOffice 4.2.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The version I downloaded from the Ubuntu PPA for LibreOffice, 1:4.2.2~rc1-0ubuntu1~ppa1, apparently includes this fix. File dialogs were incredibly slow using the version currently in the repositories for the upcoming 14.04 (Trusty) beta release. Adding the PPA and upgrading eliminated the problem. Thanks to all involved for this patch!
The problem persists in Kubuntu 14.04 and LibreOffice 4.2.3.3. However, now the bug is a bit different. The Save dialog window is not so slow, but it is slow yet. And LibreOffice crashes if you wait enought time in the save dialog window.
There shouldn't be any long delays with my recent fix, and with https://bugreports.qt-project.org/browse/QTBUG-38585 there shouldn't be even small delays.