GNOME’s quick file preview tool has finally caught up. After years of running on older foundations, Sushi now builds with GTK4. The change arrived in recent development code for what will become GNOME 51. Michael Larabel first reported the update at Phoronix on June 6, 2026.
Users know the drill. Select a file in Nautilus. Hit the space bar. Sushi pops up a floating window with a quick look at images, documents, videos or audio. No full application launch. No waiting. That convenience dates back more than a decade. Yet the code stayed tied to GTK3 while the rest of GNOME marched forward.
The port brings more than a toolkit bump. Dark mode support appears for the first time. Floating toolbars look cleaner. Layouts for several file types received careful adjustments. And the project takes initial steps toward two newer GNOME technologies: Blueprint for UI definitions and Glycin for image loading.
But why did it take so long? GTK4 introduced fundamental shifts in rendering, input handling and widget behavior. Many GNOME applications completed their transitions years ago. Nautilus itself moved years back. Sushi, as a specialized DBus-activated service, presented unique challenges. Its preview panes must handle diverse content types without disrupting the desktop flow.
Developers replaced deprecated APIs. They adapted to GTK4’s scene graph model. The result feels more consistent with current GNOME apps. Libadwaita styling comes naturally now. Animations align better. And the whole component should prove more maintainable going forward.
Glycin integration marks an interesting evolution. The library provides a safer, sandbox-friendly way to generate thumbnails and load images. GNOME began expanding its use in recent releases to reduce attack surface from malformed files. Sushi’s adoption of Glycin for previews fits that pattern. It doesn’t replace everything yet. The change remains initial. Still, the direction shows clear intent.
Blueprint, meanwhile, simplifies UI code. Instead of hand-written XML or complex widget trees, developers describe interfaces in a concise, Python-like syntax that compiles to GTK widgets. Early use in Sushi suggests the team wants to reduce boilerplate while improving readability.
Those nicer floating toolbars didn’t appear by accident. Reviewers noted improved spacing and visual hierarchy. Buttons sit where users expect them. Information displays without clutter. The refinements address years of small complaints that accumulated while the component lagged behind.
Layout changes vary by file type. Image previews now scale more intelligently. Text documents show better typography. Video controls feel less cramped. Audio tracks display album art with proper proportions. None of these qualify as headline features on their own. Together they polish an experience millions of GNOME users touch every week.
The timing aligns with broader GNOME shifts. Papers recently replaced Evince as the default document viewer in GNOME 49. That transition created ripple effects. Sushi previously depended on Evince for some document previews. Newer code adjusts for Papers where possible while maintaining compatibility.
Discussions on GNOME Discourse from October 2025 highlighted exactly these tensions. Multiple thumbnailers now compete for the same formats. Glycin offers safety but older libraries sometimes deliver better performance or quality. Prioritization questions remain active. Sushi’s updates feed directly into that conversation.
Testing on GNOME OS Nightly builds confirmed the improvements. Larabel reported smooth operation across common file types. No major regressions appeared. The dark mode worked as expected under both light and dark desktop themes. Such practical validation matters. GNOME components must feel invisible when they work and only noticeable when they fail.
Yet challenges persist. Full adoption of new preview backends takes time. Some specialized formats may still fall back to older handlers. Sandboxing adds constraints that developers continue to navigate. And community feedback will shape the final details before the next stable release.
Look at the wider context. GTK4 itself reached 4.0 in 2020. The file chooser gained icon views years later after long delays. Nautilus adopted libadwaita styling and improved search. Each piece reinforces the others. Sushi’s update completes one more link in that chain.
Users who run development versions can try the new code today. The merge request that landed the GTK4 port, titled “GTK4 Port: Fix Papers & Use Glycin,” sits merged in the Sushi repository at gitlab.gnome.org/GNOME/sushi. It builds on earlier work that prepared the ground.
Performance looks promising. GTK4’s improved rendering pipeline should reduce latency for complex previews. Memory usage may drop in some scenarios. These gains matter on lower-powered hardware where quick previews distinguish a pleasant experience from a sluggish one.
The floating nature of the preview window deserves attention. Unlike a traditional application, Sushi appears above other windows and disappears with a second space bar press or escape key. That transient behavior requires careful handling of focus, input grabs and compositing. GTK4’s changes to these systems demanded corresponding adjustments in Sushi.
So the team didn’t simply recompile. They rethought interactions. They updated keyboard navigation. They ensured accessibility tools could still read preview content. Details like these separate a functional port from a polished one.
GNOME insiders recognize the pattern. Incremental progress across many components eventually produces a cohesive desktop. Sushi’s move to GTK4 removes one item from the compatibility matrix. It lets maintainers focus on new features rather than chasing deprecations.
Future work may expand Glycin usage further. Better support for additional media types could follow. Integration with newer thumbnail databases or cloud previews remains speculative but possible. For now, the project delivers a solid foundation.
That foundation matters to distributors too. Ubuntu, Fedora, Debian and others carry Sushi as part of the standard GNOME stack. A modern codebase reduces their maintenance burden. Security audits become simpler. Backports of fixes grow easier.
And for users? The change should feel invisible. Press space. See your file. Enjoy consistent visuals with the rest of the desktop. Nothing flashy. Just reliable improvement.
Yet reliability at this layer carries weight. Previewers handle untrusted files daily. A vulnerability in Sushi could expose the entire session. Moves toward Glycin and stricter GTK4 sandboxing align with GNOME’s broader security posture.
The article at Phoronix captured community reaction quickly. Forum threads lit up with appreciation for the dark mode addition alone. Others praised the toolbar cleanup. A few asked about specific file formats still in testing.
One thing stands clear. GNOME continues methodical modernization. No single release transforms everything. Instead, steady commits accumulate. Sushi’s GTK4 port adds to that accumulation. The previewer feels fresh again. And the desktop as a whole benefits.
Developers who want to contribute will find the new code more approachable. Blueprint templates invite experimentation. Glycin’s API encourages safe loading patterns. The bar for useful improvements just lowered slightly.
Watch for the feature in upcoming GNOME 51 snapshots. Test it with your typical workflow. Report edge cases. The component that once lagged now sits on equal footing with its peers. That progress, while quiet, deserves recognition.
WebProNews is an iEntry Publication