Fuzzy text search, part 4: Search palettes & plugins

[juli27]

Part of: #15983
Depends on: musescore/muse_framework#261

This PR adds search to the plugins page and palettes.
The results on the plugins page are sorted by fuzzy score.
Palette results are sorted by fuzzy score as well. Palettes are sorted higher up when they have cells with higher score than the cells of another palette.

• I signed the CLA
• The title of the PR describes the problem it addresses.
• Each commit's message describes its purpose and effects, and references the issue it resolves. If changes are extensive, there is a sequence of easily reviewable commits.
• The code in the PR follows the coding rules.
• I understand all aspects of the code I'm contributing and I'm able to explain it if requested.
• The code compiles and runs on my machine, preferably after each commit individually. I have manually tested and verified that my changes fulfil their intended purpose.
• No prior attempts to resolve this problem exist, or if they do, I listed them in my PR description and described how I avoided repeating past mistakes.
• There are no unnecessary changes.
• I created a unit test or vtest to verify the changes I made (if applicable).

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: 0ae9723d-9e03-4acc-9a58-8ae675e238ce

📥 Commits

Reviewing files that changed from the base of the PR and between 39fb61d and 765d53b.

📒 Files selected for processing (1)

• muse

🚧 Files skipped from review as they are similar to previous changes (1)

• muse

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The palette provider now uses SortFilterProxyModel with tooltip-based fuzzy filtering, fuzzy score sorting, recursive filtering, and parent-row acceptance. The previous PaletteCellFilterProxyModel implementation and declaration were removed. setFilter now assigns a fuzzy pattern. The muse subproject pointer was advanced to a newer commit.

Merge Risk: ⚪ Minimal · up to 765d5

Palette and plugin search now use fuzzy filtering and score-based ranking, with palette-name matches preserving default cell order. No concrete merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding fuzzy text search to palettes and plugins.
Description check	✅ Passed	The description explains the changes, provides issue and dependency references, and completes the required checklist except for the unit test or vtest item. The unchecked test item is acceptable becau…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (1 skipped: 1 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

Linked repositories: Public OSS repositories can only analyze public repositories installed in this organization. No linked repositories were analyzed; skipped musescore/muse_framework.git.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Eism]

@DmitryArefiev please check searching palettes on Palettes panel

[DmitryArefiev]

@avvvvve Please try Fuzzy text search in the Palettes (it might be to much elements for one simple request)

PR's build and 4.7.5(or main):

bandicam.2026-09-01.18-11-05-240.mp4

[avvvvve]

I'm not super concerned about showing too many results for a short string like 'time'. If you continue typing more of the phrase 'time signature' the results narrow down appropriately. However, it is strange that the ordering of elements in the time signatures palette changes whether you've typed 'time ' or 'time s'.

Screen.Recording.2026-09-02.at.8.52.15.AM.mov

---

Other feedback:

It would be good if we could get exact matches to appear first in the list. Searching 'capo' does not put the actual element titled 'Capo' first—instead, the jump elements containing the word 'capo' are at the top. I'm not sure if this is in conflict with our ranking algorithm is here though, since it seemingly has to decide which order to put the palettes themselves in first before the elements within them.

---

I'm seeing a regression in element order when searching 'accidentals' between 4.7.4 and this PR. Those first four elements in the PR version should not show up at the beginning of the accidental list. I assume it's because they all have the word 'accidental' in their name, so they're ranking higher?

4.7.4 left, this PR right:

[juli27]

[...] However, it is strange that the ordering of elements in the time signatures palette changes whether you've typed 'time ' or 'time s'.

This was because some of the cells of the "time signatures" palette had "time" in their tooltip and were therefore ranked higher than the other cells which where auto accepted because the palette name matches. Once the beginning of the next word is typed, the cells no longer match and revert to their default (auto accepted) position. I've fixed this by not sorting the cells of a palette by score if the palette name matches.

It would be good if we could get exact matches to appear first in the list. Searching 'capo' does not put the actual element titled 'Capo' first—instead, the jump elements containing the word 'capo' are at the top. I'm not sure if this is in conflict with our ranking algorithm is here though, since it seemingly has to decide which order to put the palettes themselves in first before the elements within them.

Fixed! Full matches now get a small bonus to their score.

I'm seeing a regression in element order when searching 'accidentals' between 4.7.4 and this PR. Those first four elements in the PR version should not show up at the beginning of the accidental list. I assume it's because they all have the word 'accidental' in their name, so they're ranking higher?

Yes, that's why. Same cause and resolution as with "time signatures" above. Palettes whose name matches, now won't have their contents sorted by score.

Additionally, I've made it so palettes that match by name are always ranked higher than palettes with only children that match. Compare the results for "line" in 4.7 and this PR
4.7 then PR: