Revert "Rewrite Qt4 based nested yield mutex locking."

In a dbgutil build LO aborts on an assertion failure the moment
KFileDialog is open. It's definitely on okay to release SolarMutex just
like that, since the Qt event loop is integrated with LO's, it'll call
back to LO code without the mutex held.

This reverts commit 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb.

Conflicts:
	vcl/unx/kde4/KDE4FilePicker.cxx
	vcl/unx/kde4/KDEXLib.cxx

Change-Id: Idfa27fbb4728b529c37c25f710ea208fdaa4455c

2 files changed, 19 insertions, 14 deletions

diff --git a/vcl/unx/kde4/KDE4FilePicker.cxx b/vcl/unx/kde4/KDE4FilePicker.cxx
index 969fd2c082e3..b92d86f155c9 100644
--- a/vcl/unx/kde4/KDE4FilePicker.cxx
+++ b/vcl/unx/kde4/KDE4FilePicker.cxx
@@ -256,20 +256,28 @@ sal_Int16 SAL_CALL KDE4FilePicker::execute()
     _dialog->setFilter(_filter);
     _dialog->filterWidget()->setEditable(false);
 
-    // We're entering a nested loop.
-    int result;
-    {
-        // Release the yield mutex to prevent deadlocks.
-        SalYieldMutexReleaser aReleaser;
-        result = _dialog->exec();
-    }
-
+    // At this point, SolarMutex is held. Opening the KDE file dialog here
+    // can lead to QClipboard asking for clipboard contents. If LO core
+    // is the owner of the clipboard content, this will block for 5 seconds
+    // and timeout, since the clipboard thread will not be able to acquire
+    // SolarMutex and thus won't be able to respond. If the event loops
+    // are properly integrated and QClipboard can use a nested event loop
+    // (see the KDE VCL plug), then this won't happen, but otherwise
+    // simply release the SolarMutex here. The KDE file dialog does not
+    // call back to the core, so this should be safe (and if it does,
+    // SolarMutex will need to be re-acquired).
+    long mutexrelease = 0;
+    if( !qApp->clipboard()->property( "useEventLoopWhenWaiting" ).toBool())
+        mutexrelease = Application::ReleaseSolarMutex();
+    //block and wait for user input
+    int result = _dialog->exec();
     // HACK: KFileDialog uses KConfig("kdeglobals") for saving some settings
     // (such as the auto-extension flag), but that doesn't update KGlobal::config()
     // (which is probably a KDE bug), so force reading the new configuration,
     // otherwise the next opening of the dialog would use the old settings.
     KGlobal::config()->reparseConfiguration();
-
+    if( !qApp->clipboard()->property( "useEventLoopWhenWaiting" ).toBool())
+        Application::AcquireSolarMutex( mutexrelease );
     if( result == KFileDialog::Accepted)
         return ExecutableDialogResults::OK;
 
diff --git a/vcl/unx/kde4/KDEXLib.cxx b/vcl/unx/kde4/KDEXLib.cxx
index e4900a719408..24557bc6fed7 100644
--- a/vcl/unx/kde4/KDEXLib.cxx
+++ b/vcl/unx/kde4/KDEXLib.cxx
@@ -286,16 +286,13 @@ void KDEXLib::Yield( bool bWait, bool bHandleAllCurrentEvents )
         }
         return SalXLib::Yield( bWait, bHandleAllCurrentEvents );
     }
-
     // if we are the main thread (which is where the event processing is done),
     // good, just do it
     if( qApp->thread() == QThread::currentThread())
         processYield( bWait, bHandleAllCurrentEvents );
     else
-    {
-        // we were called from another thread;
-        // release the yield lock to prevent deadlock.
-        SalYieldMutexReleaser aReleaser;
+    { // if this deadlocks, event processing needs to go into a separate thread
+      // or some other solution needs to be found
         Q_EMIT processYieldSignal( bWait, bHandleAllCurrentEvents );
     }
 }