Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The Status & Future of Shutter #662

Open
delinuxco opened this issue Mar 28, 2024 · 34 comments
Open

The Status & Future of Shutter #662

delinuxco opened this issue Mar 28, 2024 · 34 comments
Labels
question Question about installing, configuring or using Shutter

Comments

@delinuxco
Copy link

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.
@delinuxco delinuxco added the question Question about installing, configuring or using Shutter label Mar 28, 2024
@DarthGandalf
Copy link
Member

DarthGandalf commented Mar 28, 2024 •
edited
Loading

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 :(

@Photon89
Copy link
Member

Photon89 commented Mar 28, 2024 •
edited
Loading

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.

@delinuxco
Copy link
Author

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?

@delinuxco
Copy link
Author

How about cheating :-)

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

@Photon89
Copy link
Member

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..

@mvivarelli
Copy link

mvivarelli commented Mar 29, 2024 via email

@Photon89
Copy link
Member

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.

@mvivarelli
Copy link

mvivarelli commented Mar 31, 2024 via email

@DarthGandalf
Copy link
Member

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.

@mvivarelli
Copy link

mvivarelli commented Mar 31, 2024 via email

@vadi2
Copy link
Contributor

vadi2 commented Mar 31, 2024

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.

@DarthGandalf
Copy link
Member

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.

@mvivarelli
Copy link

mvivarelli commented Mar 31, 2024 via email

@Photon89
Copy link
Member

Photon89 commented Mar 31, 2024 •
edited
Loading

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...

@DarthGandalf
Copy link
Member

Dunno about SelectorWaylandGnome or WindowWaylandGnome, but yes, gnome-screenshot code needs some restructuring before it can be merged - at least to allow other implementations for other compositors. Currently it just assumes that it can always work on wayland, which is false.

please Alexey, don't take my words bad, I just want the best for Shutter

Of course, not arguing that.

@Photon89
Copy link
Member

We could check whether $XDG_CURRENT_DESKTOP includes "GNOME" and whether /usr/bin/gnome-screenshot exists. If both are true, use Maurizio's code, otherwise revert to the current behavior.

@vadi2
Copy link
Contributor

vadi2 commented Mar 31, 2024

Maybe @mvivarelli you can help with the restructuring? Having Shutters code be coherent is important for the projects future.

@mvivarelli
Copy link

mvivarelli commented Mar 31, 2024 via email

@Photon89
Copy link
Member

Photon89 commented Mar 31, 2024 •
edited
Loading

If I remember well there is a function called fct_screenshot that do the X job

Exactly, but fct_take_screenshot actually does the job under all circumstances, it then decides which mode to use and calls different modules to do the job. So the differentiation between the different modes and also cases (wayland or X) happens inside fct_take_screenshot.

Also, currently your fork is 76 commits behind master, so automatically merging the changes won't be possible, even if we decided to leave them as is, without restructuring.

@Photon89
Copy link
Member

I'm not saying, we shouldn't do the restructuring and merging. We definitely should do it. It's just not that easy and trivial...

@DarthGandalf
Copy link
Member

I think it may be easier to not try to merge it as is, but look how gnome-screenshot is called with which parameters, and reimplement the Shutter side of it from scratch

@Photon89
Copy link
Member

Anybody up for discussing details and possibly do the reimplementation on IRC (https://web.libera.chat/#shutter)?

@Play-InTheWay Play-InTheWay mentioned this issue Mar 31, 2024
Open
@Photon89
Copy link
Member

Photon89 commented Apr 1, 2024

I tried reimplementing the gnome-screenshot idea now with some support by Alexey. Have a look at #667, if you'd like to test it. It's the very first working draft, still needs some work. Also, only Selection mode is supported so far.

@mvivarelli
Copy link

mvivarelli commented Apr 3, 2024 via email

@Photon89
Copy link
Member

Photon89 commented Apr 3, 2024

Hi Maurizio, yes, I guess so!

@mvivarelli
Copy link

mvivarelli commented Apr 3, 2024 via email

@mvivarelli
Copy link

mvivarelli commented Apr 15, 2024 via email

@Photon89
Copy link
Member

Great, I assume, you tested under Gnome, right?

@mvivarelli
Copy link

mvivarelli commented Apr 15, 2024 via email

@Nurmagoz
Copy link

https://tracker.debian.org/pkg/shutter

looks like shutter going to be removed from next debian release.

@vadi2
Copy link
Contributor

vadi2 commented Aug 15, 2024

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?

@Nurmagoz
Copy link

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.

@Photon89
Copy link
Member

Photon89 commented Aug 15, 2024 •
edited
Loading

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!

@Photon89
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Question about installing, configuring or using Shutter
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@vadi2 @DarthGandalf @Photon89 @Nurmagoz @mvivarelli @delinuxco