The Status & Future of Shutter

Greetings, I am wondering if anyone could share the status & future of Shutter.

Wayland support, updates on a regular bases etc.

What are the challenges for the project that hold it back from moving forward ?

etc...

This is still one of the best screenshot tools in Linux, especially for GTK environments, would hate to see it disappear.

What are the challenges for the project that hold it back from moving forward ?

Mostly lack of manpower, and horrible codebase. Ideally, to make it maintainable, need to rewrite it from perl to something more sane (rust?), but that's a lot of work.

In fact, it being perl, prevents certain wayland features - e.g. on KDE on wayland KWin checks the process which tries to access the KWin-specific screenshot API, then checks for certain values in the .desktop file of that process. Here it sees the process as /usr/bin/perl, and shutter cannot update the perl's .desktop file to add that kwin flag.

This is still one of the best screenshot tools in Linux, especially for GTK environments, would hate to see it disappear.

Agreed. When I was porting it from gtk2 to gtk3, I wanted to abandon it many times, but shutter is still better than alternatives :(

@DarthGandalf

Hi, thanks for the praise and also for worrying about Shutter's future! In my opinion, we are plainly lacking manpower and time resources.

There are many small bugs which we are trying to fix as actively as limited manpower and time resources permit, but the big challenge of adding Wayland support hasn't been worked on since @DarthGandalf implemented full screen mode for Wayland.

We'd gladly accept contributions, but currently it isn't even clear how this Wayland support might look like. The problem is that Wayland is implemented differently on different DEs and distros. For example, on Ubuntu Gnome, if you try to capture a screenshot, a dialog window pops up. Thus, there is no solution which works universally for all DEs and distros, several approaches would have to be implemented separately. For Gnome there is a fork by @mvivarelli: https://github.com/mvivarelli/shutter-on-wayland which makes use of gnome-screenshot. It is a somewhat hackish solution but it works. But to integrate it into our code, we'd need to restructure the new code, which again requires manpower and time. And it would only support Gnome for now.

Well, these are tough challenges for sure, I include Shutter in my little Manjaro Cinnamon Spin and it works great on X11. The only thing I could suggest is to make it more easier to integrate as part of a distro, add it to startup items so it is up and running even during ISO evaluation. Right now because the settings uses hard coded user paths, it is difficult.

Shutter is the one of two apps on my little spin that does not work on wayland, and I would like to keep using it, Ksnip works well, but the look on GTK desktops is not the greatest. I have enough issues keeping BackInTime looking decent. But enough about my problems.

If I may brainstorm with you here...

Is AppImage an option?

How about forking Ksnip and porting to GTK and using it as a base?

How about cheating :-)

https://www.codeconvert.ai/perl-to-rust-converter

Is AppImage an option?

This has been discussed (and even tried to some extent), see #325 and #594. But looks like we need to deal with XDG config folders first (see #492).

How about forking Ksnip and porting to GTK and using it as a base?

I think, this would be even more work than actually implementing Wayland support... 😄

How about cheating :-)

This might work well on small projects, but I wouldn't expect it to produce usable results on Shutter which consists of many modules and makes use of many dependencies, for which Rust alternatives might or might not exist, but in any case I'd expect the required changes to be too radical for such a tool to take care of them..

Hi Michael, have you verified that other DE than gnome does not have a utility like gnome-screenshot ? if turn out that they have I think that my hackish solution is by far the one that require less work to implement Maurizio

…

-----Original Message----- From: Michael Kogan ***@***.***> Reply-To: shutter-project/shutter ***@***.***> To: shutter-project/shutter ***@***.***> Cc: mvivarelli ***@***.***>, Mention ***@***.***> Subject: Re: [shutter-project/shutter] The Status & Future of Shutter (Issue #662) Date: 03/28/2024 06:13:02 PM Hi, thanks for the praise and also for worrying about Shutter's future! In my opinion, we are plainly lacking manpower and time resources. There are many small bugs which we are trying to fix as actively as limited manpower and time resources permit, but the big challenge of adding Wayland support hasn't been worked on since @DarthGandalf implemented full screen mode for Wayland. We'd gladly accept contributions, but currently it isn't even clear how this Wayland support might look like. The problem is that Wayland is implemented differently on different DEs and distros. For example, on Ubuntu Gnome, if you try to capture a screenshot, a dialog window pops up. Thus, there is no solution which works universally for all DEs and distros, several approaches would have to be implemented separately. For Gnome there is a fork by @mvivarelli: https://github.com/mvivarelli/shutter-on-wayland which makes use of gnome-screenshot. It is a somewhat hackish solution but it works. But to integrate it into our code, we'd need to restructure it which again requires manpower and time. And it would only support Gnome for now. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: <shutter- ***@***.***>

For example, xfce4-screenshooter in Xfce doesn't have the -c option which allows to put the image into the clipboard without showing the GUI at all.

And give a try to this ? https://git.sr.ht/~emersion/grim i did I little bit of investigation and saw that this module does not work in gnome/wayland but maybe it work for all the rest in this case the solution could be: - gnome-screenshot for gnome; - grim for the rest Maurizio

…

-----Original Message----- From: Michael Kogan ***@***.***> Reply-To: shutter-project/shutter ***@***.***> To: shutter-project/shutter ***@***.***> Cc: mvivarelli ***@***.***>, Mention ***@***.***> Subject: Re: [shutter-project/shutter] The Status & Future of Shutter (Issue #662) Date: 03/29/2024 12:12:26 PM For example, xfce4-screenshooter in Xfce doesn't have the -c option which allows to put the image into the clipboard without showing the GUI at all. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: <shutter- ***@***.***>

maybe it work for all the rest

Nope. It may work for https://gitlab.freedesktop.org/wlroots/wlroots only. We'll need separate solutions for different compositors, and wlroots (sway etc) has its own API for screenshots, yes, which we probably can use - via grim or directly.

reading a little bit more I found: https://www.reddit.com/r/linux/comments/11z0kcr/desktopagnostic_wayland_compositor/ maybe the solution could be: - gnome-screenshot for gnome; - solution to find for KDE; - grim for the rest but beside that, I think that if my solution is incorporated into the shutter then you pass from: - 100% support for X, 0% support for wayland to - 100% support for X, 50% support for wayland (i don't know the exact percentage of gnome and derivative usage) and in the short term this is important for not letting shutter die Maurizio

-----Original Message----- From: Alexey Sokolov ***@***.***> Reply-To: shutter-project/shutter ***@***.***> To: shutter-project/shutter ***@***.***> Cc: mvivarelli ***@***.***>, Mention ***@***.***> Subject: Re: [shutter-project/shutter] The Status & Future of Shutter (Issue #662) Date: 03/31/2024 10:39:14 AM

maybe it work for all the rest

Nope. It may work for https://gitlab.freedesktop.org/wlroots/wlroots only. We'll need separate solutions for different compositors, and wlroots (sway etc) has its own API for screenshots, yes, which we probably can use - via grim or directly. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: <shutter- ***@***.***>

Agreed. Also a very important fact of it would be managing expectations - as seen here, supporting Wayland is a lot more work than supporting X, and when Shutter does not have a certain $feature folks will be inevitably disappointed - so we need to ensure that we manage their expectations here.

from:

100% support for X, 0% support for wayland

to

100% support for X, 50% support for wayland (i don't know the exact
percentage of gnome and derivative usage)

The current state is not 0%: xdg portal support implemented in 0.99.1 is enough for very simple cases. It even supports both KDE and Gnome. It just doesn't have any more advanced features like Shutter on X did.

and in the short term this is important for not letting shutter die

Agreed, that's why I implemented that.

Now, xdg portal is not a perfect solution, but may be fine as fallback option if there's nothing better for the specific compositor. The gnome-screenshot hack you did still provides more features than xdg portal, but it works only on gnome.

So, shutter needs to detect which compositor is running, and depending on compositor, either use gnome-screenshot (or perhaps we find some better way to interact with gnome), or something specific to wlroots (e.g. grim), or something specific to KDE, etc, or to use the xdg portal as fallback.

"very simple cases" means "usable" ? becausa if does not means "usable" than I return to my evaluation:

* 100% support for X, 0% support for wayland

and usable means that you can take active window and selection screenshot please Alexey, don't take my words bad, I just want the best for Shutter Maurizio

-----Original Message----- From: Alexey Sokolov ***@***.***> Reply-To: shutter-project/shutter ***@***.***> To: shutter-project/shutter ***@***.***> Cc: mvivarelli ***@***.***>, Mention ***@***.***> Subject: Re: [shutter-project/shutter] The Status & Future of Shutter (Issue #662) Date: 03/31/2024 12:19:35 PM

from: * 100% support for X, 0% support for wayland to * 100% support for X, 50% support for wayland (i don't know the exact percentage of gnome and derivative usage)

The current state is not 0%: xdg portal support implemented in 0.99.1 is enough for very simple cases. It even supports both KDE and Gnome. It just doesn't have any more advanced features like Shutter on X did.

and in the short term this is important for not letting shutter die

Agreed, that's why I implemented that. Now, xdg portal is not a perfect solution, but may be fine as fallback option if there's nothing better for the specific compositor. The gnome-screenshot hack you did still provides more features than xdg portal, but it works only on gnome. So, shutter needs to detect which compositor is running, and depending on compositor, either use gnome-screenshot (or perhaps we find some better way to interact with gnome), or something specific to wlroots (e.g. grim), or something specific to KDE, etc, or to use the xdg portal as fallback. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: <shutter- ***@***.***>

I think we all agree that merging your code for Gnome is a good idea (@team: please correct me if I'm wrong, but this is my impression from our internal discussions). But, aside from strategic discussions, the practical problem is that it needs to be restructured a lot. Shutter stores the code for the dirty screenshooting work in modules that are located in https://github.com/shutter-project/shutter/tree/master/share/shutter/resources/modules/Shutter/Screenshot We'd need to create modules like SelectorWaylandGnome or WindowWaylandGnome which are called from the main file. The problem is just that currently we lack time to do the work...

I see it's due to a dependency that does not build on a certain platform, however a 1-line patch was attached to the dependency in question to fix the issue. Should be okay then?

I see it's due to a dependency that does not build on a certain platform, however a 1-line patch was attached to the dependency in question to fix the issue. Should be okay then?

If it will resolve the issue, it should be ok.

Well, I hope that the Debian team will figure it out!

I wanted to report issue and patch upstream but unfortunately the goocanvas project is archived and set to read-only mode, so the patch won't make it into the upstream release...

edit: There is a merge request for this upstream, but it probably won't be merged: https://gitlab.gnome.org/Archive/goocanvas/-/merge_requests/15

The patch is included in various distros already though, like in Arch or Fedora. I am optimistic that Debian will manage to include this patch as well. Thanks for the information though!

@DarthGandalf

@DarthGandalf Another news, possibly this PR will help us with Wayland support: flatpak/xdg-desktop-portal#1415

Some news regarding Wayland support:

xdg-desktop-portal has implemented basic support for so-called non-interactive targets, that is, screenshot tools like Shutter will be able to grab a selection, select a window or grab the active window: Screenshot: Add target selection API flatpak/xdg-desktop-portal#1981 The implementation has been released in version 1.21.2 (a pre-release).
xdg-desktop-portal has another PR implementing so-called capture modifiers like include_cursor and capture_delay such that Shutter can pass those options to xdg-desktop-portal. However, this PR is not merged yet: Screenshot: Prototype capture modifiers flatpak/xdg-desktop-portal#1992
The API has now to be implemented by the desktop side portals. Currently, KDE hasn't started implementation for the non-interactive targets: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/work_items/32 I couldn't find similar issues for Gnome and other DEs.
There is a PR implementing interactive access to the xdg-desktop portal, that is, once selected a capture mode in Shutter, you get a dialog from your DE where you have to select the mode again: Enable selection and window capture on Wayland via interactive XDG portal #817 It works well in Gnome, but not so well in KDE (there is no way to choose a window).
I started modifying this PR to work with non-interactive targets, but cannot do any testing because no DE has implemented them so far.
For a smooth transition, we need to ask the DE if it support non-interactive targets and fall back to either an interactive call as in Enable selection and window capture on Wayland via interactive XDG portal #817 or just disable all capture modes besides of full screen capture (that is, stay at status quo).

Apparently, on the desktop side portals, the non-interactive targets are implemented by a very recent commit of the Xapp portal (used by Cinnamon, Xfce, and Mate.)

@Play-InTheWay

@Play-InTheWay Nice, thanks for the hint, then we can do some testing before merging #818 !

@Play-InTheWay

@Play-InTheWay So I did some testing with Cinnamon. Accessing the non-interactive targets works well, the only restriction is that target 2 (window) is not implemented but it automatically redirects to 8 (active window) in the backend. I created a feature request here: https://github.com/orgs/linuxmint/discussions/1548

@Play-InTheWay So I did some testing with Cinnamon. Accessing the non-interactive targets works well, the only restriction is that target 2 (window) is not implemented but it automatically redirects to 8 (active window) in the backend. I created a feature request here: https://github.com/orgs/linuxmint/discussions/1548

Fortunately, that has now changed.

Indeed! Also, there is some progress for Xfce: xfce4-screenshooter doesn't support the window target but other than that it is now supported by xdg-desktop-portal-xapp.

I see it's due to a dependency that does not build on a certain platform, however a 1-line patch was attached to the dependency in question to fix the issue. Should be okay then?

Looks like they actually removed Net-OAuth and Shutter from testing now. Relevant issue: vurtdev/Net-OAuth#8

So, the Net-OAuth issue has been fixed by the dev, thus Shutter can return to Debian testing for the moment. But the bad news is that Shutter still has two dependencies which are no longer actively maintained and thus might soon lead to Shutter being kicked out of the repos again:

As far as I understand, goocanvas-2.0 is used in the DrawingTool, but also in the X11 Advanced Selector.
dbus-glib is used for interacting with Compiz, sending notifications and full screen capture using Wayland.pm. <- Actually, it doesn't, my bad.

In total, quite many places, unfortunately...

@gregoa

@gregoa I noticed that you take care of packaging Shutter for Debian since 0.99.6-2, so first of all thanks for the packaging work!

Luckily, the Net-OAuth issue has been fixed now, but I noticed that there are two further bug reports regarding problematic dependencies:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1134809 Indeed, the libnet-dbus-glib-perl dependency is unnecessary, libnet-dbus-perl is sufficient. I'd propose to change the dependency information and close bug 1134809.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112431 This needs to be fixed upstream, indeed. I created a PR which solves the hard dependency: Ported SelectorAdvanced.pm from GooCanvas2 to DrawingArea #826 The DrawingTool is currently still depending on GooCanvas2, but this is an optional dependency. I will have a look into porting the DrawingTool to Gtk3::DrawingArea as well though. But once Ported SelectorAdvanced.pm from GooCanvas2 to DrawingArea #826 is merged, Shutter will have no hard dependencies on outdated libraries any more.

On Wed, 12 Aug 2026 09:36:24 -0700, Michael Kogan wrote: @gregoa I noticed that you take care of packaging Shutter for Debian since 0.99.6-2, so first of all thanks for the packaging work!

Not really, I just help out as it's maintained in the Debian Perl Group where I'm a member :)

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1134809 Indeed, - the `libnet-dbus-glib-perl` dependency is unnecessary, - `libnet-dbus-perl` is sufficient. I'd propose to change the - dependency information and close bug 1134809.

Excellent, I dropped the libnet-dbus-glib-perl dependency in git.

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112431 This - needs to be fixed upstream, indeed. I created a PR which solves - the hard dependency: - #826 The - DrawingTool is currently still depending on GooCanvas2, but this - is an optional dependency. I will have a look into porting the - DrawingTool to Gtk3::DrawingArea as well though. But once #826 is - merged, Shutter will have no hard dependencies on outdated - libraries any more.

Sounds good, thanks for your work. Cheers, gregor

…

-- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `-

Sorry for late reply and thanks, gregor!

@ everybody interested:
Regarding Wayland support again: I just tested PR #818 on Fedora Rawhide on a Cinnamon Wayland session and indeed selection, window and fullscreen mode work flawlessly using non-interactive calls. Unfortunately, this only works in Cinnamon 6.7.4 which I only found in Fedora (not even Arch ships it!). But once distros include it, at least Cinnamon will get full Wayland support delivered. 😄 Unfortunately, no news in KDE: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/work_items/32 In Gnome I don't even know if there is an issue tracking this...

edit: Now there is: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/work_items/222

Navigation Menu

Repository navigation

The Status & Future of Shutter #662

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The Status & Future of Shutter #662

Description

Activity

DarthGandalf commented on Mar 28, 2024

Photon89 commented on Mar 28, 2024

delinuxco commented on Mar 28, 2024

delinuxco commented on Mar 29, 2024

Photon89 commented on Mar 29, 2024

mvivarelli commented on Mar 29, 2024

Photon89 commented on Mar 29, 2024

mvivarelli commented on Mar 31, 2024

DarthGandalf commented on Mar 31, 2024

mvivarelli commented on Mar 31, 2024

vadi2 commented on Mar 31, 2024

DarthGandalf commented on Mar 31, 2024

mvivarelli commented on Mar 31, 2024

Photon89 commented on Mar 31, 2024

16 remaining items

vadi2 commented on Aug 15, 2024

Nurmagoz commented on Aug 15, 2024

Photon89 commented on Aug 15, 2024

Photon89 commented on Aug 15, 2024

Photon89 commented on May 23, 2026

Play-InTheWay commented on May 25, 2026

Photon89 commented on May 25, 2026

Photon89 commented on May 26, 2026

Play-InTheWay commented on May 26, 2026

Photon89 commented on May 26, 2026

Photon89 commented on Aug 9, 2026

Photon89 commented on Aug 10, 2026

Photon89 commented on Aug 12, 2026

gregoa commented on Aug 12, 2026

Photon89 commented on Aug 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions