Merge lp:~mzanetti/gsettings-qt/queued-processing into lp:gsettings-qt

[Michael Zanetti]

sync event processing with the Qt event loop

[Albert Astals Cid (aacid)]

Looks a bit workaround-ish, i'm not opposing to it, but maybe a TODO to try to find the real cause of it?

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:68
http://jenkins.qa.ubuntu.com/job/gsettings-qt-ci/34/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/gsettings-qt-vivid-amd64-ci/1/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/gsettings-qt-vivid-armhf-ci/1/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/gsettings-qt-vivid-i386-ci/1/console

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/gsettings-qt-ci/34/rebuild

review: Needs Fixing (continuous-integration)

[Lars Karlitski (larsu)]

Closing this in favor of lp:~lukas-kde/gsettings-qt/queued-processing

Unmerged revisions

68. By Michael Zanetti on 2015-02-02

add comment

=== modified file 'GSettings/gsettings-qml.cpp'
--- GSettings/gsettings-qml.cpp	2014-06-23 14:55:54 +0000
+++ GSettings/gsettings-qml.cpp	2015-02-02 10:24:24 +0000
@@ -135,7 +135,10 @@
     if (schemaValid) {
         priv->settings = new QGSettings(priv->schema->id(), priv->schema->path(), this);
 
-        connect(priv->settings, SIGNAL(changed(const QString &)), this, SLOT(settingChanged(const QString &)));
+        // There seems to be some context issues if this is a Qt::DirectConnection. E.g. if a setting is used in a
+        // condition for a Loader source, the Loader won't destroy the old item any more. Switching to a
+        // Qt::QueuedConnection, which effectively syncs processing to the Qt event loop, fixes that issue.
+        connect(priv->settings, SIGNAL(changed(const QString &)), this, SLOT(settingChanged(const QString &)), Qt::QueuedConnection);
 
         Q_FOREACH(QString key, priv->settings->keys())
             this->insert(key, priv->settings->get(key));