feat(core): redesign unified search result presentation

[pringelmann]

• Resolves: Result presentation: cap per category, "More from …", detail view #61652
• Resolves: [Bug]: Pressing ctrl+f a second time does not allow native search #62626

Summary

Reworks how unified search presents results, per the design in #61652.

The aggregate list now shows at most three rows per category, each group headed by a "More from …" control that opens that category's full result page in a detail view. Result rows show their provider's real icon instead of a generic one.

-> Preview link <- (u:bob, p:bob)

Smaller fixes from the same pass:

• Refining a query keeps the previous results on screen while the new ones load, instead of flashing an empty panel.
• A second Ctrl+F falls through to the browser's find bar.

Design feedback already captured

The following feedback items were already captured. They will land in a follow-up PR: I want to get the core work merged, then we iterate.

• We do show "Ctrl K" as shortcut, but the more commonly known (?) shortcut Ctrl-F also works. Would it not be better to show that so people know they can use their muscle memory for that? (For the few people who already use that F shortcut)
• The shortcut looks veeery prominent visually if it’s there all the time. Might be good to only show on hover or so?
• When focusing/clicking into the field, suggestions of any kind would be good. Right now the quick filters are hidden behind the "filter" icon on the right instead of being shown, and we could show recent searches (or suggested results)
• Result sorting is a bit odd. Here in files I have a matching filename, but an app/setting is shown before?
  Also see screenshot: the PDF filetype icon is too small and also blue
• "Apps" is sorted first instead of current app?
• Detail: Double horizontal line on "Partial matches"
• When I'm diving into a result type where the top filters could apply, they should be available to further refine the search at a later step. for instance when I dive into files, I would still keep "date" and "people" around

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI (mostly tests)

[pringelmann]

@susnux thanks for adding labels, but I am going to remove the bug label since the unified search feature is still very much a work in progress, and the previous subtask PRs merged to master have not implemented all the requirements yet. Is that OK with you?

[kra-mo]

Really really nice!

We do show "Ctrl K" as shortcut, but the more commonly known (?) shortcut Ctrl-F also works. Would it not be better to show that so people know they can use their muscle memory for that? (For the few people who already use that F shortcut)

CtrlF should be used for in-app searches and is already used by Talk and Collectives. We should both probably implement this shortcut for all in-app search fields, and also rename them to "Filter" (where it makes sense) or otherwise "Find" to disambiguate and make the shortcut easier to infer as well. CtrlK is then for global search. These shortcuts with this local/global distinction is also used by apps like Slack and Discord.

The shortcut looks veeery prominent visually if it’s there all the time. Might be good to only show on hover or so?

Right, but that would unfortunately not help keyboard-only users, or users with a touchscreen and keyboard, but no mouse (e.g. tablets). While the latter is not that prominent, the former is more so, and they are the ones that should especially know about the shortcut. There are some options, like inlining it or similar, then it would also work for screen readers. But I will think about it. In any case, prominent shortcuts like this are at least common, so.

Result sorting is a bit odd. Here in files I have a matching filename, but an app/setting is shown before?

"Apps" is sorted first instead of current app?

Apps always being first is I think crucial to make unified search a nice experience for switching. Windows, Mac, iOS, and GNOME all do this with their global search. Local results being second I think makes sense, since if you are specifically only looking for those, you should use in-app search which we should also have.

I tested it, my feedback:

• The padding for when only filters are shown may be uneven? Like there is more padding on the bottom than on the top?
• Clicking the filter button doesn't seem to actually work?
• The selected item actually doesn't have enough contrast like this. It should probably have a pill on the left to indicate it is selected like the left navigation and list items.
• The foreground for this icon is incorrect:

The rest is great :)

[pringelmann]

Thanks for the feedback @kra-mo , I will fix the minor UI issues.

Apps always being first is I think crucial to make unified search a nice experience for switching. Windows, Mac, iOS, and GNOME all do this with their global search. Local results being second I think makes sense, since if you are specifically only looking for those, you should use in-app search which we should also have.

Ordering is set per provider, so we can tune it as needed. And yes, Apps is deliberately pinned above everything since it's the launcher, and below that the current app's provider should lead. That mostly holds, but the values are inconsistent (user management currently ranks itself near the bottom on its own page), so I'll audit the core providers and normalize them.

Longer term we could also bucket the providers server-side, so the current app's block always comes right after Apps even when the app's own provider doesn't ask for it. There isn't always a clean mapping between the app in the route and the provider's app ID though, so in those cases we'd fall back to the order the provider specifies.

Either way, this can happen iteratively :)

Clicking the filter button doesn't seem to actually work?

You mean in the sense that it does not open the filter dropdown at all? I tested on both FF and Chromium, across various apps, and it always opens for me. Do you see any errors in the console?

[kra-mo]

That mostly holds, but the values are inconsistent (user management currently ranks itself near the bottom on its own page), so I'll audit the core providers and normalize them.

Longer term we could also bucket the providers server-side, so the current app's block always comes right after Apps even when the app's own provider doesn't ask for it. There isn't always a clean mapping between the app in the route and the provider's app ID though, so in those cases we'd fall back to the order the provider specifies.

Yeah, that is nice.

You mean in the sense that it does not open the filter dropdown at all? I tested on both FF and Chromium, across various apps, and it always opens for me. Do you see any errors in the console?

Yes, in Safari, no errors that I can see.

[jancborchardt]

Right, but that would unfortunately not help keyboard-only users, or users with a touchscreen and keyboard, but no mouse (e.g. tablets). While the latter is not that prominent, the former is more so, and they are the ones that should especially know about the shortcut.

@kra-mo @pringelmann yeah, sorry I said only to show it on hover, but if it’s shown on both hover and focus it would be fine? Then 1 time you have to tab into it as a keyboard user, but then you know the shortcut.

[kra-mo]

But focus makes you be able to type directly.

In any case, I will explore options for making it less distracting.

[pringelmann]

@kra-mo I fixed the minor UI issues as well as the safari bug (will make sure to test in Safari in future before opening PRs)

[kra-mo]

1. We have variables for clickable elements and headings now. They should be used: --font-weight-element and --font-weight-heading.
2. The bar doesn't seem to appear for me properly and the Apps entry still has a dark foreground (although don't spend too much time fixing it because of #62728).

Screen.Recording.2026-08-03.at.16.54.38.mov

Looks nice otherwise :)

[pringelmann]

@kra-mo I've fixed the fonts and bar rendering on safari. The incorrect app icon color is not related to the PR, but rather my preview env setup. (I will fix this at some point)

[kra-mo]

Sorry, this one is still not --font-weight-element:

Once that's fixed, consider this approved :)

And another thing I just happened to notice but don't take it as blocking this PR is that on mobile, the text for the filters can start truncating early enough so the icons should probably either be hidden at a certain breakpoint, or the alignment should change depending on size:

[pringelmann]

/compile rebase