Everything 1.4.1.771b : Items selection problem after scrolling on the ETP client side.

[merlinpimpim]

Items selection problem after scrolling on the ETP client side

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 !!

Can you fix this bug ?

Thanks

[void]

It's currently a limitation with ETP.

Selection is done client side, I need to do selection server side.. It's on my TODO list.

You can only select what is currently displayed with ETP.

This issue occurs in all releases of Everything.

[merlinpimpim]

It's on my TODO list.

Great !

Thank you.

[V@no]

I don't know how Everything works, but why does the selection must come from the server? I thought it's client side feature...

[void]

Selection is currently client side only.

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]

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...

[NotNull]

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 ...

[V@no]

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.

Again I probably comparing here apples with oranges..

[NotNull]

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)

[void]

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.

[hicla]

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!

[stop]

thanks hicla, the thumbnail trick helped me with my current problem.

it would be nice if this could be fixed at some point, I mostly use everything to search my nas on a server from the clients I use. also I'd done dozens of searches for 'can't select all' and 'can only select one page of results' before I found this, hoping adding these words to this topic helps someone else.

[mnambiar]

Is there any solution to this? We use an ETP server do scanning a shared drive and search results are limited to whats visible. Would be great if export or select all would export the whole result set. Thanks

[void]

No solution yet, sorry.

Server side selection is on my TODO list.

[merlinpimpim]

On the todo list for 4 years.

[NotNull]

On the todo list for 4 years.

Don't be overly dramatic, it was only 2321257 minutes ...

In all fairness: in that same period 200 updates were released for Everything. Things that needed fixing/improving.
New functionalities will be introduced in the next major version of Everything (1.5).
That list contains almost 500 (!!) "things to do" and I bet it is only half of it (is your request on it?).


Given that @void is basically a one-man-band that also has to maintain the website, answer forum questions, remove spammers, fix exotic problems and what have you that takes up a lot of time. And all that next to living a regular life just like you and me.
I think we have to be *very* grateful for whatever time he is able to spend on further development of Everything.


My advice: Don't complain, donate! Keep Everything alive.

[merlinpimpim]

I have already contributed financially since I discovered Everything in 2014. Twice.
But thanks for the information and sorry if I seemed unpleasant.
My next donation will be after testing this famous version 1.5!

[NotNull]

@merlinpimpim: It was not directd at you, but in general, for everyone reading this. This was a good situation for "promoting" donations.
Sorry if I came across that way.

I just wish that it helps more people to consider donation. To help @void. And thus Everything. And thus themselves...

[xpk]

Today I have discovered this problem when trying to export in the latest stable Everything ETP client. I don't need the filelist functionality per-se, but I hoped to use it as a workaround for integrating remote ETP and local indexes into a single Everything instance. And I do need to integrate the ETP and local indexes into single instance of Everything, because I don't see how to invoke IPC queries to different Everything instances via the SDK DLLs.

[void]

ETP only has access to a small window of results at one time.

Please consider the Everything Server (in development).
The client will have a local copy of the index when using the Everything Server.