Skip to content

feat(YouTube - Settings): Add ability to search in settings #4881

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

Merged
merged 95 commits into from
May 17, 2025

Conversation

MarcaDian
Copy link
Contributor

@MarcaDian MarcaDian commented Apr 29, 2025

Adds search feature to YouTube ReVanced settings:

  • Implements fuzzy matching for more flexible search results.
  • Adds a dropdown search history (up to 5 entries), shown once before typing begins.
  • Allows removing history items by long-pressing on them.
  • Displays a "no results found" message when there are no matches.
  • Supports searching through categories, switches, and list preferences.
  • Highlights matched keywords instantly within the results.
  • Matches the visual style of the original YouTube UI.

Screenrecorder-2025-05-10-14-09-01-727.gif

@oSumAtrIX oSumAtrIX changed the title feat(YouTube - Settings): Add SearchView to ReVanced settings feat(YouTube - Settings): Add ability to search in settings Apr 29, 2025
@oSumAtrIX
Copy link
Member

Regarding

Implement search in external SB and RYD fragments (or rewrite them)

A rewrite to implement it via the preferences framework would be ideal. It would restore consistency with other preferences and also allow searching. May be out of scope of this PR, but would be welcome in it as well.

@oSumAtrIX
Copy link
Member

@LisoUseInAIKyrios Do you think if a fuzzy search would be possible? Casing, spacing and co is something many would have to trial and error for probably.

if (TextUtils.isEmpty(query)) {
restoreOriginalPreferences(preferenceScreen, originalPreferenceScreen);
} else {
String queryLower = query.toLowerCase();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also strip spaces? "sponsorblock" and "sponsor block" would match.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or things like ', " etc. Lowercase alphabet would be ideal probably. @LisoUseInAIKyrios what do you say?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the exception of "SponsorBlock" and "Sponsor Block", I don't think the preference text has any ambiguos spacing or punctuation that would affect searching. Even if searching for "sponsor block", the SponsorBlock settings will show before they get to "block". Using a combination of individual word searches (if little to no results exist) I mentioned would also fix this since "sponsor block" would show the combined search of each word "sponsor" and "block".

Since the results show up as the user is typing, I think they may stop when the result they want is shown.

Copy link
Member

@oSumAtrIX oSumAtrIX Apr 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the preference text has any ambiguos spacing

That's just an assumption. There's no benefit in including spaces in search. It's only beneficial for the statistics to omit them from the search as it's more unlikely to be useful in search than not useful

Comment on lines 223 to 224
sortPreferenceListMenu(Settings.CHANGE_START_PAGE);
sortPreferenceListMenu(Settings.SPOOF_VIDEO_STREAMS_LANGUAGE);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@LisoUseInAIKyrios Searching should be possible via the base implementation of the settings patch, so when we add the patch to other apps, its there as well. Isn't this implemented in the wrong place?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only simple solution is to make a self sorting preference list, but there's nuances to that since for this use case the first list element should always be first (so 'default' or 'disabled' is always first).

The biggest headache of doing that is the way preferences are programmatically created during patching, then serialized to xml, then de-serialized during runtime. Because of the xml serialization it makes adding extra custom parameters very difficult or overly complex (such as do not sort the first N preference list elements).

The best solution is to not do the xml serialization/deserialization and instead create all preferences at runtime, similar to how ReVanced TikTok does it. Then all kinds of extra data and behavior could easily be added to the preference objects and not what RV YouTube does with clunky static methods modifying stock Android Preferences.

Making that change is way outside the scope of this PR and would be a lot of work to accomplish, but it would both simplify things and open up a lot of use cases that are difficult or almost impossible to do right now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR would break compilation on the attempt to separate the shared patches to their own extension as the youtube unspecific patch references youtube specific settings. For that the code needs to be restructured

@LisoUseInAIKyrios
Copy link
Contributor

Regarding

Implement search in external SB and RYD fragments (or rewrite them)

A rewrite to implement it via the preferences framework would be ideal. It would restore consistency with other preferences and also allow searching. May be out of scope of this PR, but would be welcome in it as well.

Doing it for RYD would be fairly simple since it doesn't have any custom behavior except the API stats (but those could be handled using a custom preference that hides itself if debug is off).

But converting all of SB would be way more substantial, since it has a lot of custom code to validate/fix user input, show custom colors/segments, user stats, and more.

@LisoUseInAIKyrios

This comment was marked as resolved.

@LisoUseInAIKyrios
Copy link
Contributor

@LisoUseInAIKyrios Do you think if a fuzzy search would be possible? Casing, spacing and co is something many would have to trial and error for probably.

Fuzzy search would be ideal, but obviously adds complexity.

Other fuzzy search ideas are if multiple words are searched for, and the search results are few (less than maybe 10), then show the combined search results of each word individually (and stop combining sub searches when 10+ results exist).
 

But fuzzy doesn't handle if a user searches for a different wording of a preference. Preferences could declare related words that are silently searched against. So SponsorBlock could declare [ "sponsor block", "sponsors", etc ]

Another example is disable resuming Shorts (Preference summary is: Disable resuming Shorts player, Shorts player will not resume on app startup) could declare related words such as ["resume", "launch", "open"].

@oSumAtrIX
Copy link
Member

But fuzzy doesn't handle if a user searches for a different wording of a preference.

That's correct behavior. Fuzzy aids the user and prevents light spelling mistakes. It doesn't make attempts to guess what the user might search. The guess approach doesn't look ideal. It won't be useful in most or make weak guesses at what the user might or might not type. Fuzzy search is sufficient on the other hand. I don't think it adds any complexity other than a library for fuzzy searching

@oSumAtrIX

This comment was marked as resolved.

@oSumAtrIX
Copy link
Member

oSumAtrIX commented Apr 29, 2025

But converting all of SB would be way more substantial, since it has a lot of custom code to validate/fix user input, show custom colors/segments, user stats, and more.

If inputs needs validation a custom input component can be made. Similarly the color and popup ones. Or those can be removed and they can consistently use the same input preferences as other preferences. Consistency is more important here which would also solve side effects as seen in this PR

@LisoUseInAIKyrios

This comment was marked as resolved.

@oSumAtrIX

This comment was marked as resolved.

@oSumAtrIX

This comment was marked as resolved.

@oSumAtrIX

This comment was marked as resolved.

@LisoUseInAIKyrios

This comment was marked as resolved.

@oSumAtrIX

This comment was marked as resolved.

@oSumAtrIX

This comment was marked as resolved.

@LisoUseInAIKyrios

This comment was marked as resolved.

@oSumAtrIX

This comment was marked as resolved.

@LisoUseInAIKyrios

This comment was marked as resolved.

@MarcaDian

This comment was marked as resolved.

@LisoUseInAIKyrios

This comment was marked as resolved.

@MarcaDian

This comment was marked as resolved.

@MarcaDian
Copy link
Contributor Author

After re-entering the settings, are they displayed in the correct order?

@LisoUseInAIKyrios
Copy link
Contributor

Yes. If a previous suggestion is reused it then shows first the next time suggestions are shown.

@LisoUseInAIKyrios
Copy link
Contributor

Oops, no they don't. They're back to whatever order the preferences saved them as.

Will need to somehow include ordering when saving them to the preferences.

@LisoUseInAIKyrios
Copy link
Contributor

Maybe don't use the preference set method, and instead save the suggestions to a single StringSetting by concatenating the suggestions by new lines. Then settings import/export could also save the history if desired.

@MarcaDian
Copy link
Contributor Author

MarcaDian commented May 10, 2025

can be used JSON (JSONArray)

@LisoUseInAIKyrios
Copy link
Contributor

It's better if the settings all fit on one line, to keep import/export a bit cleaner. Other settings already use new lines to store multiple values to a single setting.

@LisoUseInAIKyrios
Copy link
Contributor

Seems ready to go.

Copy link
Member

@oSumAtrIX oSumAtrIX left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last comments I sent would ideally be addressed. Rest LGTM. Thanks for the huge effort on everyone involved in this PR

@LisoUseInAIKyrios LisoUseInAIKyrios force-pushed the add_searchbar_to_settings branch from 9d1af83 to d4f840b Compare May 16, 2025 17:13
@LisoUseInAIKyrios LisoUseInAIKyrios merged commit aca8b20 into ReVanced:dev May 17, 2025
1 check passed
github-actions bot pushed a commit that referenced this pull request May 17, 2025
# [5.24.0-dev.5](v5.24.0-dev.4...v5.24.0-dev.5) (2025-05-17)

### Bug Fixes

* **Spotify - Fix third party launchers widgets:** Add missing compatibility annotation ([0493f80](0493f80))

### Features

* **YouTube - Settings:** Add ability to search in settings ([#4881](#4881)) ([aca8b20](aca8b20))
@MarcaDian MarcaDian deleted the add_searchbar_to_settings branch May 17, 2025 08:05
@LisoUseInAIKyrios
Copy link
Contributor

I just noticed now, but the SponsorBlock categories no longer shows the category description. Probably needs a custom ListPreference.

Screenshot_20250518_120803_YouTube

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.

feat(YouTube): Add search functionality in the revanced settings to find things quickly
4 participants