Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve search behavior in the file browser #7679

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

sakertooth
Copy link
Contributor

@sakertooth sakertooth commented Feb 2, 2025

This PR revamps the search functionality within the file browser, with the intent of improving the code and user experience.

Changes:

  • All the search logic is now in FileBrowser::onSearch. As such, FileSearch was removed. This should make the search functionality more easy to follow.
  • Search results are no longer shown in a hierarchy, but instead as a flat list, with only the found directories being hierarchical. This aligns better with most file managers and greatly simplifies the search code (no need to convolute things by attempting to build a hierarchy). Since only the name of the directory or file that matches the filter is shown, path information has been added to the context menu for both items (as well as an "Open" and "Close" action for directory items).
  • Searching now considers all files regardless of their extension. This is because extensions have no bearing on what kind of file a file is. This should open doors to allow finding for esoteric files that have unusual extensions but are perfectly working as they should, or files that are perfectly supported but have an odd extension.
  • Searching now follows symlinks.
  • Searching now supports finding hidden files if the "Hidden content" checkbox is enabled. Likewise, it will ignore hidden files if the checkbox is disabled.
  • Stop checking for paths to exclude from listing/searching (explained in 1a9643f)
  • Uses tokenization instead of matching the entire search filter

@sakertooth
Copy link
Contributor Author

For some reason while searching, there is a segfault when closing the program. Doesn't seem to be a concern, but unsure why this happens.

Reducing the search space for performance is no longer a problem now, so there's no harm in allowing these directories to be considered (and we can avoid potential problems with how files are organized on users machines). Making sure to always check agaisnt the blacklist was also a bit error-prone since its possible to forget to check against it (like with how searching was implemented here, but it did not seem to matter at that point).
@sakertooth sakertooth marked this pull request as draft February 4, 2025 22:02
@sakertooth sakertooth marked this pull request as ready for review February 4, 2025 22:56
Most notable differences are that we cancel the search automatically in the destructor when closing the application, and we use a mutex to prevent ordering conflicts when beginning and ending searches.
@AW1534
Copy link
Contributor

AW1534 commented Feb 5, 2025

Searching no longer considers extensions.

Does this mean I can no longer, for example, type "mid" and see all my midis? this is something I do often and I think this behaviour should be preserved.

@sakertooth
Copy link
Contributor Author

sakertooth commented Feb 5, 2025

Searching no longer considers extensions.

Does this mean I can no longer, for example, type "mid" and see all my midis? this is something I do often and I think this behaviour should be preserved.

No, it's just that the search is no longer limited by files with certain extensions. Instead, the search now considers all files regardless of its extension. If you type "mid", it will treat it as a token and find any file that has it in its name. ".mid" will probably find all midis for you.

I did this because if a file was named "foo.medi" but was a perfectly working midi file, then the search wouldn't find it if it considered extensions regardless if the search filter was for e.g. ".medi".

Since we always cancel the search if one is already running before starting up a new one, theres no need for mutual exclsuion since the cancellation logic should provide that.
We shouldn't update the search indicator directly in the onSearch function because those updates may get out of order with the updates that are queued by the auxiliary thread, potentially resulting in inconsistent state.
@sakertooth sakertooth changed the title Revamp searching in the file browser Improve search behavior in the file browser Feb 6, 2025
@bratpeki bratpeki self-assigned this Feb 18, 2025
@bratpeki
Copy link
Member

Is this ready for testing?

@sakertooth
Copy link
Contributor Author

Is this ready for testing?

Feel free.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants