-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
base: master
Are you sure you want to change the base?
Conversation
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).
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.
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.
Is this ready for testing? |
Feel free. |
This PR revamps the search functionality within the file browser, with the intent of improving the code and user experience.
Changes:
FileBrowser::onSearch
. As such,FileSearch
was removed. This should make the search functionality more easy to follow.