I Built a Screenshot Tool for Linux Wayland Because My Workflow Broke
I use screenshots constantly.
A quick capture to explain something. An arrow pointing at a bug. A box around a UI element. Some text added to make a point. Occasionally, OCR to extract something from the screen.
For a long time, Flameshot was my go-to screenshot tool on Linux.
And honestly, I still love it.
It has a great workflow, excellent annotation tools, and it just feels right for the way I work.
But then I moved from X11 to Wayland.
That’s when things started getting frustrating.
Wayland changed the experience
Flameshot wasn’t suddenly a bad application. The problem was that the environment underneath it had changed.
Wayland has a fundamentally different screen-capture model compared with X11. Depending on the desktop environment and configuration, I started running into capture issues, portal-related behavior and other rough edges that simply weren’t part of my old X11 workflow.
I wasn’t particularly interested in going back to X11 just because I wanted a screenshot.
I also found myself wanting something else that Flameshot didn’t provide natively:
OCR.
When I screenshot an error message, terminal output, documentation or some piece of text on screen, I often want the text itself rather than just the image.
That meant taking the screenshot, opening another OCR tool, extracting the text and then continuing with whatever I was doing.
It was another little piece of friction.
I tried the alternatives
Before deciding to build something myself, I went looking for alternatives.
I tried tools such as ApexShot, ClipShot and a few other screenshot solutions in the Linux/Wayland ecosystem.
Some of them had really interesting ideas.
Some had significantly more functionality than I expected.
But I kept running into the same problem:
They didn’t fit the workflow I wanted for a tool I use dozens of times a day.
Some felt too complicated. Others felt over-engineered. Some had so many features and UI elements that the basic act of taking a screenshot started feeling like an application workflow rather than a simple desktop action.
And that’s not necessarily a criticism of those projects.
They’re solving different problems and some are genuinely impressive.
I just realized that I didn’t want a sophisticated screenshot application.
I wanted a really good screenshot utility.
Something I could summon, drag, annotate if necessary, copy and forget about.
For a daily-use application, I wanted the tool to almost disappear.
That distinction became the foundation for FrameShot.
I wasn’t trying to replace Flameshot
This is important.
FrameShot exists because I liked the workflow of Flameshot, not because I thought Flameshot was a bad tool.
The basic idea of selecting an area and immediately annotating it is exactly the kind of interaction I wanted to keep.
I just wanted to rebuild that experience around a Wayland-first architecture, while adding the things I was missing.
My ideal workflow became:
Press a hotkey → select an area → annotate → OCR if needed → press Enter → done.
The screenshot should already be in my clipboard.
No application window.
No import dialog.
No unnecessary save dialog.
Just the screenshot.
The workflow I wanted
I didn’t want another screenshot application with a big window, menus and configuration screens getting in the way.
I wanted:
Hotkey → select → annotate → done.
That became the core philosophy behind FrameShot:
The best screenshot interface is almost no interface at all.
What FrameShot adds
FrameShot keeps the parts of the traditional screenshot workflow I like and adds a few things that I personally found missing.
Native Wayland capture
FrameShot is designed around Wayland rather than treating Wayland as an afterthought.
It has capture paths for GNOME, wlroots-based compositors and KDE, with appropriate fallbacks where available.
On GNOME, it uses a small Shell extension to perform capture within the compositor environment, avoiding some of the portal friction that can otherwise appear during interactive screenshots.
Built-in annotation
The capture and annotation happen in the same overlay.
You can add:
- Rectangles
- Ellipses
- Arrows
- Lines
- Freehand drawings
- Blur/pixelation
- Text
No separate editor is required.
OCR without leaving the screenshot
This was one of the biggest reasons I wanted to build FrameShot.
Get rohith’s stories in your inbox
Join Medium for free to get updates from this writer.
Select the content, capture it, hit OCR, and the extracted text appears directly in the screenshot workflow.
You can edit it and copy it.
No switching applications.
Text as an actual object
Text isn’t simply burned permanently into the image the moment you type it.
You can move it, resize it, rotate it, recolor it, edit it or delete it.
That makes correcting annotations much less painful.
Clipboard first
Most screenshots I take are temporary.
I paste them into Slack, a terminal, a browser, an issue tracker or a document and never need the actual file.
So FrameShot treats the clipboard as the default destination.
Press Enter and the image is copied.
Saving to disk is optional.
Fast by design
FrameShot runs a background daemon so the application doesn’t need to cold-start every time you press the screenshot hotkey.
The hotkey communicates with the daemon through a lightweight socket path, allowing the capture overlay to appear very quickly.
On my setup, the summon path is around 40 ms.
The goal isn’t to build a benchmark champion.
The goal is for taking a screenshot to feel instantaneous.
Built for the Wayland desktop
Wayland isn’t one single environment.
GNOME, KDE, Sway, Hyprland and other compositors have different capabilities and integration points.
FrameShot is designed with that reality in mind.
It supports multiple capture backends and can create per-output overlays for multi-monitor setups.
There’s also a diagnostic command:
frameshot doctorwhich checks things like the capture backend, portal availability, GNOME extension state, permissions and configuration.
Because when screenshot capture breaks on Linux, knowing why it broke is half the battle.
What FrameShot isn’t
FrameShot isn’t trying to replace every screenshot utility on Linux.
If you need completely headless screenshots from a script, grim or another CLI-oriented tool may be a better choice.
If Flameshot works perfectly for you on your current setup, keep using it.
I would.
FrameShot is for people who want something closer to this:
Hotkey → drag → annotate → OCR → Enter → clipboard.
And who want that workflow to feel native on Wayland.
Why build instead of just waiting?
I could have waited for the existing tools to improve.
And they probably will.
But building FrameShot was also an opportunity to explore what a screenshot application designed specifically around modern Linux desktops could look like.
It started as a personal annoyance and turned into a proper open-source project.
That’s one of the things I love about Linux.
If something doesn’t quite work the way you want, you can build it.
What’s next?
FrameShot is still actively evolving.
There’s a lot I’d like to improve:
- More compositor integrations
- Better annotation tools
- Faster OCR
- More keyboard-driven workflows
- Better automation
- More polish around multi-monitor setups
- And, of course, fixing the weird edge cases that only appear on someone else’s Linux setup.
That’s where community feedback becomes important.
There are too many combinations of distributions, desktops, compositors, GPUs and display configurations for one developer to test everything.
Try it
FrameShot is free and open source under the MIT license.
If you’re a Linux user who has moved from X11 to Wayland and found your screenshot workflow getting worse rather than better, I’d love for you to try it.
If it works for you, a GitHub star helps the project get discovered.
If it doesn’t, open an issue.
And if you have an idea that would make the workflow better, I’d genuinely like to hear it.
Because FrameShot started with a very simple frustration:
I loved my screenshot workflow.
Then I moved to Wayland.
So I built the workflow I wanted back.
