There is a big problem on ETP client side:
- Do a search with many results (from ETP server)
--> Ctrl+A selects only the items displayed, not all items results !
--> Scroll the screen deselects items !!

ETP only provides a small window of results, if selection was done client side and server side it would allow for scrolling and keeping the selection, rather than limiting the selection to the small window of results.

V@no wrote:But client already knows number of total items and index of selected item...I guess I'm comparing it with how it's done in javascript...

Suppose you have a database of 10GB (RAM) server side, while you have a client with 2GB RAM and do a "stupid" query on it, like searching for "." ....

In that case you will be glad that the Everything server sends "just enough" data to the client to present just a page (/a few pages) full of results.
Not only because otherwise it wouldn't fit in the client memory (causing swapping at least), but also causing to "download" about 10GB of query results to the client.

Long story short: I think it's a good idea that not all query results are available on the client right away.
And as Ctrl-A on the client can only select the results that it's aware of, this will be a subset

@void: another route would be to let Ctrl-A fetch all results from the server and select that. Don't know if that's feasible; just trying to help ...

NotNull wrote:In that case you will be glad that the Everything server sends "just enough" data to the client to present just a page (/a few pages) full of results.
Not only because otherwise it wouldn't fit in the client memory (causing swapping at least), but also causing to "download" about 10GB of query results to the client.

I understand sending just enough result per page, but point is, client already knows at what position it shows in the list (just look at he scrollbar), it also knows what index in the list is selected (at least it could know) ...unless the selection stores not just indexed numerical of each selected entry in the list, it could be done client side.

V@no wrote:but point is, client already knows at what position it shows in the list (just look at he scrollbar), it also knows what index in the list is selected (at least it could know) ...unless the selection stores not just indexed numerical of each selected entry in the list, it could be done client side.

No, you're right. That's how it works (AFAIK). Unless ...

.. there are more search results than fit on one page in the client. In that case Ctrl-A only selects the objects currently on the screen. If you do a PgDown (for example) to show more results, the current page is discarded and a new page is loaded. This will "kill" your current selection.
(see original question of this thread)

The client result list and server result list can become out of sync.
For example index 1001 on the client may refer to a completely different result on the server after some time.

The results on the server side continue to change dynamically, although the client can not see these changes straight away.
Having the client update in real-time is on my TODO list.

Everything uses the full path and filename to keep in sync, not an index.

@void: another route would be to let Ctrl-A fetch all results from the server and select that. Don't know if that's feasible; just trying to help ...

I will have to think about this some more, what I had planned was Ctrl+A would select all results client side and server side, however, pressing enter would only run the currently visible results on the client. I'll consider downloading all the filenames to be executed.. maybe some limit would work, eg: 1000 files.

Resurrecting this old topic to add my +1 to this bug report and offer a partial workaround:
it is possible to select many more results by switching from the Details view to the Medium Thumbnails one (I wish there was a "Small Thumbnails" one!)
You can typically squeeze an extra row of results by zooming out (CTRL + -) a few times
From 69 objects selected in the details view, you could select 945.

One more thing not mentioned in this bug report: the Export command (CTRL + S) is affected as well

@void, about the 1000 items limit you were considering in the last post: it might seem high, but it definitely isn't enough for us. If you go with a limit, please make it configurable. Thank you!