https://bugs.kde.org/show_bug.cgi?id=436373
--- Comment #4 from Aleix Pol <aleix...@kde.org> --- Git commit c0e9cb9376ca5348a214458532a0611832f12f71 by Aleix Pol Gonzalez, on behalf of Aleix Pol. Committed on 30/09/2021 at 11:02. Pushed by apol into branch 'master'. kns: Centralise the backend query state handling We put it all into ::setResponsePending which is the function that we call to tell we are embarking on a new query. This allows us to make sure the signals to wrap up the previous state can be emitted as well as notifying about the new state accordingly. This also allows us to assert when the state isn't as expected, which allowed to address some issues already as it's done in this change. Hence, this fixes: - issuing 2 searches before the backend has initialised will result in an infinite job as both queries would be waiting forever for the backend to initialise. - issuing 2 searches where the first is pageable would leave the second idling forever even though it's the one we care about. - checking for updates didn't check whether we are already querying, we could get 2 tasks weirdly overlapping - fetchMore wouldn't notify about starting to fetch - fetchEntryById isn't paged - findResourceByPackageName wouldn't reset the m_responsePending value Related: bug 432965 M +69 -37 libdiscover/backends/KNSBackend/KNSBackend.cpp M +2 -0 libdiscover/backends/KNSBackend/KNSBackend.h https://invent.kde.org/plasma/discover/commit/c0e9cb9376ca5348a214458532a0611832f12f71 -- You are receiving this mail because: You are watching all bug changes.
