Fix premature firing of allInitialized signal

In case this is in fact the first backend to be added, and also
happens to be pre-filled, we still need for the rest of the
backends to be added before trying to send out the initialized
signal. To ensure this happens, this patch schedules it for the
start of the next run of the event loop, and ensures that it
only happens if there are no more backends to initialise.

Specifically, this happens if e.g. the fwupd backend is the
first to be initialised, and results in (amongst other things)
that the application loads up and insists that there are no
application backends.

Differential Revision: https://phabricator.kde.org/D18246
BUG: 401334
parent b5910935
......@@ -119,10 +119,18 @@ void ResourcesModel::addResourcesBackend(AbstractResourcesBackend* backend)
connect(backend, &AbstractResourcesBackend::passiveMessage, this, &ResourcesModel::passiveMessage);
connect(backend->backendUpdater(), &AbstractBackendUpdater::progressingChanged, this, &ResourcesModel::slotFetching);
if(m_initializingBackends==0)
emit allInitialized();
else
// In case this is in fact the first backend to be added, and also happens to be
// pre-filled, we still need for the rest of the backends to be added before trying
// to send out the initialized signal. To ensure this happens, schedule it for the
// start of the next run of the event loop.
if(m_initializingBackends==0) {
QTimer::singleShot(0, this, [this](){
if (m_initializingBackends == 0)
emit allInitialized();
});
} else {
slotFetching();
}
}
void ResourcesModel::callerFetchingChanged()
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment