I don't think adding a (rather massive) delay is the real fix here. It only masks the actual issue.

What really happens (just opened the discover store for the first time ever) is that entries can flow in at any point, that might be an issue.
Every batch can contain items for any position in the in the store.

The query used to fetch the data should fetch it in order of appearance. That would fix the visual clutter issue you described.

Secondly (but this is outside the scope of this report) it should probably implement a incremental loading logic. Right now it seems to fetch everything.

In D5767#108088, @markg wrote:

I don't think adding a (rather massive) delay is the real fix here. It only masks the actual issue.

What really happens (just opened the discover store for the first time ever) is that entries can flow in at any point, that might be an issue.
Every batch can contain items for any position in the in the store.

The query used to fetch the data should fetch it in order of appearance. That would fix the visual clutter issue you described.

Secondly (but this is outside the scope of this report) it should probably implement a incremental loading logic. Right now it seems to fetch everything.

I think you might be misunderstanding the base intention of postponing the search here... We do not have a giant data centre to host the kde store, where the search goes to, so we can't simply afford to swallow the many unneeded requests the existing delay causes. This is a part of a wider effort to ensure we only send requests to that server that we actually intend to make. You are correct, however, that this is in no way enough on its own, but we already caused a manual ddos on api.kde-look.org week before last, which caused a shutdown for about a day, and if we can avoid that in the future, we need to do so. This helps (only sends searches we want), but we do also need to batch and combine the searches (which needs to happen elsewhere, and as you say is outside the scope of this patch).

It could make sense to move this to the KNSBackend, any appstream-based backends don't have such a problem.

In D5767#108234, @apol wrote:

It could make sense to move this to the KNSBackend, any appstream-based backends don't have such a problem.

Good point indeed - while it isn't really kns specific, we don't have any other backends that go online to do any searching at the moment, so... yeah, i'll prepare a new patch with that in mind (i'll update this revision with the new patch, as the problem and (most of) the solution is the same, just in a different location)

Sry for seeming obtuse here but isn't the results from previous queries saved between sessions and displayed for the search?

I mean I see that when doing a search within "Plasma Addons" you get the left hand column bouncing around since it loads all the categories? Shouldn't at least that be saved and just edited if something has actually changed?

In D5767#108317, @jensreuterberg wrote:

Sry for seeming obtuse here but isn't the results from previous queries saved between sessions and displayed for the search?

I mean I see that when doing a search within "Plasma Addons" you get the left hand column bouncing around since it loads all the categories? Shouldn't at least that be saved and just edited if something has actually changed?

Not really, we don't save past searches. Maybe we should. We don't have changed information from OCS.