KDE Discover Redesign: Concrete UI Ideas to Make It Feel at Home on the Desktop
Discover’s real problem isn’t that it looks bad
The desktop layout just hasn’t been pushed as hard as the mobile one. Discover is built on Kirigami — KDE’s convergent UI framework — which means the same components running on a Plasma phone have to work equally well on a 2560×1440 monitor. Most of the time they do. But you can feel where the desktop-specific tuning stopped.
KDE developers have been chipping away at this steadily, and recent Plasma 6 releases show real progress. The April 2026 “This Week in Plasma” post noted that app page headers got a visual overhaul with more prominent install buttons. Earlier updates tightened margins, replaced separator lines with whitespace, and switched web URL buttons to plain underlined links — all in line with the KDE Human Interface Guidelines. These incremental fixes compound over time.
But there’s a gap between what’s been fixed and what the community is still asking for. The redesign thread on KDE Discuss keeps surfacing the same requests. Here’s what actually seems worth filing as concrete proposals.
The sidebar and hero banner problem
Open Discover on a wide desktop monitor and the left sidebar takes up a significant chunk of real estate. The category list inside isn’t long — the column width just hasn’t been constrained for larger viewports. On a 1080p screen it feels fine. On anything wider, it starts to feel wasteful.
The hero banner at the top of the app list is a similar issue. On mobile, a large image fills the screen usefully — it’s the focal point. On a desktop where several apps are visible at once, that same banner just pushes real content down. A collapsible or shorter banner variant for desktop widths would be an easy win without removing the feature for smaller displays.
Grid cards instead of a tall list
This is the single change community members mention most often. Search results currently appear as a tall single-column list: one row per app, icon on the left, name and short description beside it. It works. It uses vertical space poorly.
A grid of rectangular cards — each showing icon, name, a short tagline, and a star rating — would let you scan three or four times as many results per scroll. Apple’s App Store and the GNOME Software center have both moved toward this pattern for a reason: you don’t have to read each row linearly; your eye jumps to whatever looks relevant. Mock-ups that community members have posted in the KDE Phabricator redesign task (T12668) show how dramatic the difference can be in practice.
The KDE Kirigami framework supports grid layouts natively, so this isn’t a framework limitation — it’s a design decision waiting to be made.
Search and filtering
Discover sorts results by popularity, measured by number of ratings. Reasonable default. No way to switch it. Adding a sort dropdown — “Recently Updated,” “Alphabetical,” “Highest Rated” — is a small change that has an outsized effect on usability, especially when popular results happen to be unrelated to what you typed.
Category filtering inside search results would help too. Search “video editor” and want only Flatpaks, or only applications rather than Plasma add-ons? There’s no clean way to narrow that down mid-search. Discover does differentiate between desktop add-ons and regular applications, which is actually one of its stronger points compared to GNOME Software — that distinction just isn’t surfaced at search time, where it would be most useful.
Screenshots and reviews
The app detail page got a polish pass in recent Plasma 6 releases, but reviews still feel easy to miss. Many apps have star ratings with almost no written text behind them, and the ones that do exist aren’t highlighted.
Showing a one-line review snippet on a grid card in search results — not the full review, just a fragment — would make the rating feel less abstract. Right now a 4.2-star rating tells you almost nothing without clicking into the app page to see context.
Screenshots live in a horizontal scroller on the app detail page, which is fine. A quick-preview overlay on a search result card — without navigating away — would speed up comparisons when you’re looking at several options side by side.
The Flatpak and native package split
Discover handles the coexistence of native distro packages and Flatpaks better than some alternatives. Both show up in the same view, and the source label is visible. The feedback from users isn’t that the system is broken — it’s that when both a native package and a Flatpak exist for the same application, the tradeoffs between them aren’t explained anywhere in the UI.
A short tooltip or inline note — something like “Native: system-integrated; Flatpak: more frequently updated” — would help less-experienced users make a real choice instead of defaulting to whichever appears first. The mislabeling issue where standard apps sometimes appeared as outdated beta Flatpaks has been addressed in Plasma 6.x updates, which removes one source of confusion.
Performance on first launch
Discover can be slow to open when it’s rebuilding its AppStream metadata cache or syncing Flatpak repository data. This is partly a background indexing problem rather than a UI one, but it shapes how the whole application feels. A user who hits a long blank screen on first launch is less likely to open Discover again.
Showing a labeled loading indicator — “Refreshing app catalog…” — instead of a blank window is a low-effort change. The data takes the same time either way. A user who knows what’s happening will wait; a user staring at nothing often won’t.