ksnip was using the same DBus Interefaces as Spectacle (here) but at some point the usage got restricted and only known apps, basically only KDE apps, were allowed to use it so we, like all other screenshot tools, had to fall back to the portal screenshot which leave a lot of people unhappy and are ,IMHO, in it's current form, unusable if you desire a smooth user experience.

This does not affect only KDE but also Gnome where the same happened with Version 41, the good screenshot interface got restricted to internal use and we had to fall back to portal screenshots.

For quite some time I need to explain to some unhappy ksnip users, at least once a week, that knsip is not broken it's just how things work now under Wayland.

Anyways, thanks for your feedback.

Ah, if GNOME also maintains their own internal protocol to get a good screenshot UX on Wayland, that really does suggest that the Wayland screenshot protocol or how it's implemented in compositors needs a re-think. Seems like a classic case at an attempt to increase security pushing people to seek out less security in order to not be annoyed to death all the time.

ksnip was using the same DBus Interefaces as Spectacle (here) but at some point the usage got restricted and only known apps, basically only KDE apps, were allowed to use it so we, like all other screenshot tools, had to fall back to the portal screenshot which leave a lot of people unhappy and are ,IMHO, in it's current form, unusable if you desire a smooth user experience.

You need to specify the restricted interfaces you need in your desktop file:
X-KDE-DBUS-Restricted-Interfaces=org.kde.kwin.Screenshot,org.kde.KWin.ScreenShot2

If you want a different workflow, it would be useful to have the full conversation. We obviously cannot grant every process access to the screenshots infrastructure.

You need to specify the restricted interfaces you need in your desktop file:
X-KDE-DBUS-Restricted-Interfaces=org.kde.kwin.Screenshot,org.kde.KWin.ScreenShot2

We already have that but it doesn't seem to always work and we had it for a while. Also, I have been told somewhere that this is just a temporary workaround and will be removed at some point.

If you want a different workflow, it would be useful to have the full conversation. We obviously cannot grant every process access to the screenshots infrastructure.

I would wish for the portal interface to remember given permission by an application and don't show the redundant dialog every time I want to take a screenshot. Something like we have now with all mobile phones, try to get some resource, ask the user for permission and remember the selection and don't ask again. On the next usage, we are getting the resource directly, no need to click in ksnip "take screenshot", then in the dialog "select type", then "confirm", then click "share", this is just too much clicking and confirming for a smooth UI experience. There was some talk and development in that direction but I'm not sure far that got into the KDE and GNOME world flatpak/xdg-desktop-portal#649

Ah, if GNOME also maintains their own internal protocol to get a good screenshot UX on Wayland, that really does suggest that the Wayland screenshot protocol or how it's implemented in compositors needs a re-think. Seems like a classic case at an attempt to increase security pushing people to seek out less security in order to not be annoyed to death all the time.

The portal interface was a step in the right direction, something generic that looks and can be used the same on Plasma, GNOME, Sway... like it used to be under X11 (the interaction at least) but just the additional dialog and all the confirmation might be secure but are all but user friendly, people avoid wayland because they cannot work as they are used to from X11, Windows or MacOS, it's just not practical.

Hi,

any news on this topic? I'd like to switch to wayland and the only thing stopping me is that I can't take screenshots of rectangular area using ksnip

By now, I can take rectangular screenshots in wayland using spectacle and automatically open them in ksnip (that way I can benefit from the editing tools and tabs of ksnip) with this command:

screenshot_filename=$(date +%Y%m%H%M%S)".png"; spectacle -r -b -n -o $screenshot_filename; ksnip $screenshot_filename

It's a big mess, but for what I need, it works!

thats a great idea!
I was using the "Print"-Key for making Area-Screenshots.
Also im using Gnome so i dont want to install spectacle.

I built a wrapper script that uses gnome-screenshot, and I bound it to my Print key again.

#!/bin/bash
temp_dir="/tmp"
screenshot_filename="$temp_dir/screenshot_$(date +%Y%m%d%H%M%S).png"

# Take a screenshot of an area and pass to ksnip
gnome-screenshot -a -f "$screenshot_filename"

if [[ -f "$screenshot_filename" ]]; then
    echo "Screenshot saved to: $screenshot_filename"
    ksnip "$screenshot_filename"
    rm -f "$screenshot_filename"
else
    echo "Screenshot failed."
fi

It's working fine, and I can use my beloved Ksnip for editing area screenshots.

I adopted the script for using spectacle as above, but saving the file directly into the Screenshots folder and adding wl-copy from wl-clipboard package to put the image into the clipboard directly. (Hint: Shift+ESC closes the ksnip window)

#!/bin/bash
screenshot_filename="${HOME}/Pictures/Screenshots/screenshot_$(date +%Y%m%d-%H%M%S).png"
spectacle -r -b -n -o $screenshot_filename

if [[ -f "$screenshot_filename" ]]; then
    wl-copy < "$screenshot_filename"
    ksnip "$screenshot_filename"
fi

I'm on Ubuntu 24.04 with wayland and found that to get the mouse pointer AND a chrome <select> dropdown captured, I had to turn on Ubuntu zoom with gsettings:

#!/bin/bash
screenshot_filename="/tmp/screenshot_$(date +%Y%m%d%H%M%S).png"

gsettings set org.gnome.desktop.a11y.applications screen-magnifier-enabled true
gnome-screenshot -p -d 2 -a -f "$screenshot_filename"
gsettings set org.gnome.desktop.a11y.applications screen-magnifier-enabled false

if [[ -f "$screenshot_filename" ]]; then
  ksnip "$screenshot_filename"
  rm -f "$screenshot_filename"
fi