[Enhancement] Searching file view does not filter view directly

[Doodeletion]

Searching the file view does not filter the view immediately but rather displays a dropdown of matching files. You can only see the file contents when selecting a file from the dropdown. Once a file is selected, the file view will only show that one file. If you're searching for multiple similarly named files, you have to start a separate search for each one.

After selecting RepositorySettings.cs from the dropdown:

I think it would be better if the search filtered the view directly instead of searching a dropdown.

[love-linger]

See #775

[Doodeletion]

Oh sorry, I forgot to search for duplicates before opening this.

I see, that's a valid concern. But given that searching is supported now, wouldn't it be possible to temporarily store the matched files and display them instead of the full file tree? (So only building the tree representation for the matched files)

[love-linger]

Imagine the following situation: In the case where you have just entered the first few characters, all the files may match the filter, so the number of files displayed is still too large. And currently, for the UI thread to not get stuck, SourceGit only shows the first 100 matching files.

[Doodeletion]

You are right, but why not use the same workaround for the treeview? When a user types to search, only render the first 100 files in the treeview (or display a warning instead of the tree, saying that the search is not specific enough).
And the searchbox binding could use a delay, so the search only starts when nothing has been typed for a while. This would also mean that if the characters are typed quick enough, the first search might already be specific enough.

[mithom]

I would love for this issue to progress, at least in the discussion side.
would you be willing to look at suggested code implementations that take your concerns into account?
I'm not git wizard, but I know my way around performance. together maybe we can find create something working.

[mithom]

i think the performance issue can be solved using 2 principles

• keep the scroll-box with a maximum of 100 files.
• when typing, instead of showing an empty tree list, show a message: 'make your search more specific to show the file tree
• when there are only 100 files or less matching the search. Create the tree, possibly collapsed to save resources when > 20 files

possible extra to discuss: make the 100 and/or 20 a setting the user can configure.

alternative approach:

• keep everything as it is now
• allow the user to select multiple files from the scroll-box by using shift/alt
• create the tree for all selected files instead of for only 1