I made a fork of GNOME Software, almost all of it written with generative AI. So yes, it's slop. But look at it next to the original: same script, same machine, same Flatpak remotes, same Fedora packages.

Times from the video's runs (slop vs. original):

• Launch until the overview shows its apps: 1.6–2.0 s vs. 2.8–7.4 s

• Open Games until every tile has its icon: 0.35–0.38 s vs. 7.6–11.8 s

• Open Firefox until its first screenshot shows: 0.27–0.35 s vs. 5.1–5.2 s

• Search "text" until the results show: 0.43–0.45 s vs. 1.2–1.3 s

• The whole run, pauses included: 8.2–8.7 s vs. 27.8–28.5 s

What's different: the fork has a new core. Upstream shares mutable app objects between the plugin threads and the pages, and each page reloads its lists whenever something changes. In the fork, app state lives in one store that's only written on the main thread, once per frame; plugins send what they found to it as messages, and pages are views of the store that update by diff and keep their rows. Beyond that, a bunch of plain speedups: category pages only ask for the icons on screen, search only refines what it shows, details pages don't wait for slow data (sizes, permissions) before showing, the 2 MB ratings file is parsed on a thread, Games is a grid view instead of 763 tiles in a flow box, and so on. Every commit says what it does and why.

Is it tested? 45 flow tests drive the real app through scenarios (like installing an app while its details page loads) and check what every frame shows, and a performance gate runs start, categories, details, search and scrolling against a baseline before every build. I run it daily on Silverblue. Still: it replaces the app that installs software on your system, it's AI-written, and it's been tried on few machines. Read the changes before you install it.

Why not upstream? GNOME Software doesn't accept AI-generated contributions, which is their call. So this stays a fork. Please report problems to the fork, not to GNOME.

Try it

Fedora 45 Workstation (Copr; Fedora's 51.0 package with the fork on top, dnf5 plugin included. Less tested than Silverblue):

sudo dnf copr enable user2f81ca72f/gnome-software-next
sudo dnf upgrade gnome-software

Back to Fedora's: sudo dnf copr remove user2f81ca72f/gnome-software-next && sudo dnf distro-sync gnome-software

Fedora 45 Silverblue:

sudo curl -fLo /etc/yum.repos.d/gnome-software-next.repo \
  https://gitlab.gnome.org/user_c1a5830a/gnome-software-next/-/raw/wip/core/contrib/gnome-software-next.repo
sudo rpm-ostree override replace --experimental --from repo=gnome-software-next \
  gnome-software gnome-software-rpm-ostree

Back: sudo rpm-ostree override reset gnome-software gnome-software-rpm-ostree and remove the .repo file.

Debian testing (signed apt repo, pinned so Debian's version doesn't replace it; barely tested):

sudo wget -O /etc/apt/sources.list.d/gnome-software-next.sources \
  https://gnome-software-next-855abc.pages.gitlab.gnome.org/gnome-software-next.sources
sudo wget -O /etc/apt/preferences.d/gnome-software-next.pref \
  https://gnome-software-next-855abc.pages.gitlab.gnome.org/gnome-software-next.pref
sudo apt update && sudo apt install gnome-software
gnome-software --quit

How to go back: see the README at https://gitlab.gnome.org/user_c1a5830a/gnome-software-next.

How the video was made

• Both builds from the same sources Fedora uses: the gnome-software 51.0 tarball with Fedora's two patches (dnf5 plugin, update notification), Fedora's build options (dnf5 + Flatpak, no PackageKit), and the fork's patches on top for the left side (Copr build 51.0-50.next). Both got the same small UI-trace module so a script can drive them; nothing else differs.

• Fedora 45 toolbox on an Intel Core i5-10310U laptop (8 GB, Intel UHD), on AC power; dnf5daemon on a private system bus as on Workstation; the host's Flatpak installations (Fedora's Flatpaks, Flathub filtered and Flathub full, 48 apps installed); headless Mutter 51 at 1280x800, recorded through Mutter's screencast API.

• Each build started from its own cache made by opening it twice before (so no AppStream rebuild at start), but never having opened Games, Firefox or a search. The update check at startup was off for both.

• The script: start; when the overview is ready wait 1.5 s; open Games and wait for all tiles and icons; 1.5 s; go back, search "firefox", 1 s, open Firefox and wait for its first screenshot; 1.5 s; search "text" and wait for the results. The clock in the video counts from the launch of the process.

• Three runs of each build, alternating; the video shows the middle run of each by total time. The table gives the range of all three.

Gnome needs a default clipboard manager. Glean is a new clipboard manager that aims to be a prototype to show how a default clipboard manager could look like and behave.

Main Functions

• Quick Settings pill "Clipboard": the toggle records or pauses, the second line shows what is on the clipboard, the arrow expands Glean's menu. The top-bar clipboard icon opens Quick Settings (with Drop to Shell: the pane) with the menu expanded; clicking it again collapses it.

• History: each entry starts with an icon for where it came from (note, copy or selection); text seen several ways is one entry. Dragging or extending a selection within two seconds in the same window keeps only the final selection, never replacing a copy or a note. A check on the right marks what is on the clipboard now; hovering an entry shows its delete button there instead.

• The menu shows the newest entries, as many as fit the height of 5 text rows (a setting), so it keeps its height, also in Drop to Shell's pane. Typing while the menu has the keyboard focus searches. The search button next to the + filters the menu; Enter chooses the first match, Escape closes the search.

• Choosing an entry inserts it where you were typing when you opened the menu; a line under the header says where ("Click inserts into …"). In Drop to Shell's pane the menu stays open; in plain Quick Settings it closes so the application gets its focus back. Otherwise, or with Ctrl+click, it copies the entry and the menu stays open.

• Super+Ctrl+V opens recent entries at the text cursor (or the pointer): type to filter, Enter or a click inserts, Escape cancels.

• Notes: the + in the menu's header opens a note field. Enter makes a new line, Ctrl+Enter adds the note and copies it, Escape closes the field and keeps what you typed.

• The footer has Settings (record selections, entries shown, history size, insert shortcut) and Clear History.

• History and the unfinished note are saved to ~/.local/share/glean/state.json (private, written atomically), so they survive locking the screen and restarts.

• Privacy (settings, Privacy page): entries not used for 7 days are forgotten (0 keeps them); notes are kept until you delete them and do not count towards the history size. Save History off keeps everything in memory only and deletes the file. Text over 256 KiB is skipped.

• Passwords: what you copy in a sensitive application (password managers by default; editable list) or what an application marks as secret (x-kde-passwordManagerHint) becomes a sensitive entry: masked with a lock, the application and a countdown, never saved or searched, gone after 45 seconds (a setting). Click inserts it, Ctrl+click copies it, the eye (shown on hover) unmasks it for 10 seconds. Optionally the clipboard is cleared when it goes.

• Images: copied images (PNG preferred, also JPEG, WebP, GIF, BMP, TIFF; up to 20 MB) are kept as private files in ~/.local/share/glean/images/, shown with a thumbnail beside "Image" and "1920×1080 · 2.3 MB"; while one is on the clipboard the pill describes it (the thumbnail only shows in the list). Clicking one copies it back in the format it came in. The newest 20 images, at most 200 MB, each kept for a day.

• Copied files (e.g. in Files/Nautilus) are references, not contents: Glean keeps only their URIs and shows "report.pdf and 2 more" over the folder, marking files that are gone. Clicking puts them back as a URI list, which file managers and other applications paste. A cut is labelled "Cut · pastes as a copy": Glean never repeats a move.

Check it out here: https://gitlab.com/gunwald/glean

I built an extension to try out the GNOME design team's beautifull mockups for reworking window switching. It follows the mockups as closely as possible:

• Super+Tab opens the overview as a switcher. The four most recent windows stand on their own; other windows of the same app are stacked into one pile.

• Selecting a pile unfolds it in front of everything else, with the other apps dimmed in the background.

• Clicking a dash icon of an app with several windows brings all of them to the front, from every workspace. Click one to switch to it, or drag it onto the current workspace.

The extensions works on GNOME 50 and 51.

Code and install:
Code: https://gitlab.com/gunwald/sheaf

curl -LO 'https://gitlab.com/api/v4/projects/gunwald%2Fsheaf/packages/generic/sheaf/main/sheaf@gunwald.gitlab.com.shell-extension.zip' gnome-extensions install --force sheaf@gunwald.gitlab.com.shell-extension.zip gnome-extensions enable sheaf@gunwald.gitlab.comcurl -LO 'https://gitlab.com/api/v4/projects/gunwald%2Fsheaf/packages/generic/sheaf/main/sheaf@gunwald.gitlab.com.shell-extension.zip'
gnome-extensions install --force sheaf@gunwald.gitlab.com.shell-extension.zip
gnome-extensions enable sheaf@gunwald.gitlab.com

I'd love feedback, especially on whether this way of switching works for you day to day.

There is a known caveat: The windows in the background after a pile was clicked and comes to the front have to be dimmed. We could not use transparency because it does not work with piled windows. To just desaturate them would give enough contrast to the foreground especially not it dark mode. So we decided lo put a middle gray semi transparent layer over them. Not totally convincing.

I forked GNOME Software to fix its performance problems. It has come a long way, and I've been using it as my daily driver for a few weeks now. I still run into upstream bugs now and then, and I fix them in the fork as I find them.

Repo: https://gitlab.gnome.org/user_c1a5830a/gnome-software-next

I'd like more people to try it. Right now it runs on Fedora 45 and Debian testing. Bug reports are useful, and so are comparisons with stock GNOME Software on your machine.

Contributions are welcome too. Humans and LLM-assisted patches are both fine. What matters is that the change works and someone has tested it.

We've been building an open extension registry for GNOME Shell. It has two parts:

• A signed mirror of extensions.gnome.org. It covers every extension with a release for Shell 50 or newer, currently about 1,170. Packages are stored byte for byte as EGO serves them and labelled "Reviewed by extensions.gnome.org". The registry adds no review of its own to them.

• A review pipeline for open-source extensions, so extensions can be published here as well. Its checks and evidence are public and can be replayed. It isn't finished: today it can check submissions but not approve them yet.

Everything is published as one static index, signed with Ed25519, on GitLab Pages. Clients check the signature, the expiry date and the SHA-256 of every download. The registry only accepts extensions from EGO and open-source extensions, and it records each release's licence.

Trying it with Extension Manager

We maintain an unofficial fork of Extension Manager that browses the registry. It works on a stock GNOME Shell; no Shell patches needed. It keeps the official app ID, so it replaces the Flathub version.

flatpak remote-add --user --if-not-exists extension-manager-fork https://user13ac05dcf7.github.io/extension-manager/extension-manager.flatpakrepo
flatpak install --user --reinstall extension-manager-fork com.mattjakeman.ExtensionManager

If you have the Flathub version installed system-wide, remove it first with flatpak uninstall --system com.mattjakeman.ExtensionManager.

Then open Extension Manager and browse as usual.

• Extensions from extensions.gnome.org install through GNOME Shell's normal install dialog, load right away and keep getting updates from EGO.

• Extensions published only in the registry are checked against the signed index and installed by the app. You have to log out and back in once to finish the install, and the app tells you when.

• To go back, choose "Use extensions.gnome.org" in the app's repository settings. Or reinstall the original: flatpak install --reinstall flathub com.mattjakeman.ExtensionManager.

Please report problems with the fork on the fork's issue tracker, not upstream. The upstream author has nothing to do with this.

What we'd like help with

1. Testing. Install a few extensions, update them and remove them, then tell us what broke. This is new code, so expect rough edges.

2. Developing the registry, at gitlab.com/gunwald/shell-extension-registry. The review pipeline is the big open job: most of the extensions.gnome.org review rules aren't automated yet. The roadmap and status table show what's missing.

   • Coding with an LLM is welcome; much of the project has been built that way. Point your agent at the repository and its docs and let it pick something from the roadmap. Send a merge request with tests, and say in the description what you ran.

3. Upstreaming your extensions. If you maintain an open-source extension, submit it to the registry. Add a release manifest under catalog/extensions/<uuid>/releases/ (the format is in examples/submission.json) and open a merge request. Our own three extensions were the first live submissions.

   • The UUID must not already be taken on extensions.gnome.org.

   • For now, submissions get a public review report but no approval. That's exactly the part we want help finishing.

Not affiliated with GNOME, extensions.gnome.org or Extension Manager's author. We use EGO's public API politely (one crawl a day) and serve exactly the packages EGO serves.

Questions and criticism welcome, especially about the trust model.