Test merge 818 828

[Photon89]

@DarthGandalf@underwaterdba

I tried to resolve the conflicts between #818 and #828. Cannot do any multimonitor testing though.

[Photon89]

So, now, according to my testing, the current state supports both the redo from #828 and the xdg-portal targets from #818. I cannot test whether multimonitor capture works as expected though. A new $screen_mode variable, which has been initially introduced by AI while trying to solve the merge conflict, is supposed to tell whether we are talking to the current monitor or not (defined in line 6337). It is passed to Wayland::xdg_portal but not used there. I cannot tell if it is useful because of lacking testing on multimonitor...

[Photon89]

I connected my PC's monitor with my laptop and set up two virtual monitors in my KDE VM. Indeed, this PR allows selecting each of the monitors or capture both of them:

I will try to adjust the screenshot name (name of the chosen monitor, if a specific one has been captured), and also do more testing on Gnome and Cinnamon.

[Photon89]

Ready for review now!

[underwaterdba]

I have pulled this branch and tested on Fedora 44 - Gnome 50; functions work as expected for selection, whole workspace and selecting monitors.

[underwaterdba]

Hitting a bug with Redo, hitting f5 does not respect previous selection of single monitor.

[Photon89]

thanks for testing! What exactly happens instead of repeating the previous screenshot?

[DarthGandalf]

Thanks, I'll copy here the comment from #828 :

resources/modules/Shutter/App/Common.pm uses a different (more modern) way to create a class and properties; shouldn't this do the same?

and perhaps this should inherit from Shutter/Screenshot/Main.pm like other screenshotters do? though not sure what specifically it needs from there

[Photon89]

As far as I understand, the super class provides four parameters: shutter_common (_sc?), include_cursor, delay and notify_timeout. Wayland.pm needs _sc, _interactive, _target, _screen_mode (probably can be kicked out) and _monitor. So the only common parameter is _sc. Don't know if it makes sense to equalize the calls here if there are so many differences so far. I hope that at some point xdg-desktop-portal will implement capture modifiers into their screenshot API (include_cursor and delay), see flatpak/xdg-desktop-portal#1992, maybe then we can refactor a bit?

[DarthGandalf]

Sure, makes sense. And the first question?

[Photon89]

To be honest, I'm not sure how this modern way works and I haven't seen it in other screenshotter modules so far, so should Wayland.pm be the only one to use it? Also, I fear, my vacation ends soon and it would be great if we could make a new release before this happens. 😄 Rewriting the class creation part sounds like it would take quite a lot of time, at least if I am to do it, because I have no idea, how it works...

[DarthGandalf]

hm, I could try, but without wayland and multiple monitors I have no meaningful way to test it. Oh well

[Photon89]

If you have some spare time, you could set up a virtual machine with a Wayland distro for testing and activate a virtual second screen in the virtual machine's settings. In #829 I summarized which DEs work which way, so the best results are expected in Fedora Rawhide Cinnamon (hint: You need to exchange LightDM with GDM before switching to a Wayland session, otherwise it crashes). But @underwaterdba and I did the testing and I think, in terms of functionality it works well, the only question is whether the code changes need improvement in terms of code quality.

[DarthGandalf]

If you have some spare time

Not any time soon

[Photon89]

I see... thanks for your on point remarks which you could still provide! In this case, let's merge it and hope the best! What shall we do about the other open PRs? At least they are much smaller, except for the SelectorAdvanced rewrite...

[underwaterdba]

It captured the whole workspace (all 4 screens).

…

On Wed, Aug 19, 2026 at 11:02 PM Michael Kogan ***@***.***> wrote: *Photon89* left a comment (shutter-project/shutter#830) <#830 (comment)> thanks for testing! What exactly happens instead of repeating the previous screenshot? — Reply to this email directly, view it on GitHub <#830?email_source=notifications&email_token=ALH7YL5YED4SRWVCAEXIAJ35KYPXTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZUHA2TGOBUGI4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5348538428>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALH7YLZQNF5S2YQ3HQQ566L5KYPXTAVCNFSNUABFKJSXA33TNF2G64TZHMZDOMJVHE3TKNJYHNEXG43VMU5TKMJXGEYDQOJUHE32C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ALH7YL35FDH7NS2EC4TDN5T5KYPXTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZUHA2TGOBUGI4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ALH7YL4UCHWH6RU55O7EFGL5KYPXTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZUHA2TGOBUGI4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[Photon89]

Yeah, I could reproduce it, I'll look into it, thanks!

[Photon89]

I think, redo is fixed now. One issue remains which is not fixable though, redo after a non-fullscreen capture. What it currently does is just launching another xdg-desktop-portal call with the same target. For example, if the user had last used the selection mode, it will again launch the selection mode, but it won't be able to just get the same selection as in the last run. Same with the window mode. We can either disable the redo button if the last screenshot wasn't fullscreen, or keep it the way it is, because maybe it's better than nothing.

[underwaterdba]

tested redo on Fedora 44 - gnome 50 working as expected. both Window and Selection are using the built-in snapshot tool

[Photon89]

@underwaterdba Yes, this is expected till Gnome implements the non-interactive targets.

@DarthGandalf I think, this is once again ready for review!