Thanks for reporting. What Fedora version are you using?

Tested just now with latest ksnip installed as snap and AppImage on Ubuntu Gnome Wayland, seems to be working, I was ableto take a screenshot and copy paste it into an email in GMail in browser. I think I have a Fedora 31 VM installed, testing with it next.

Works also in Fedora 31 running Gnome (the default one, not Classic and not xorg) which seems to be Wayland according the XDG_SESSION_TYPE variable. Here I have tested with ksnip 1.7.2

The steps that I do:

• Open ksnip
• Take screenshot, now visible in ksnip
• Open Firefox
• Login into gmail
• Click compose, this opens a new window for creating a new email
• Switch to ksnip, click copy
• Switch back to the new email window
• Paste image via CTRL+V
• Screenshot now visible in email

You doing any of those steps differently?

Ok, I'll try installing Fedora 32 next, this is the one which didn't work for you initially?

I have now installed Fedora 33 beta in a Virtual Machine but I still cannot reproduce the issue, I'm able to take a screenshot and copy it into LibreOffice

Same with gmail in Firefox

Can you try on your side installing Fedora 33 beta in a VM in VirtualBox and just download the ksnip AppImage and try out copy pasting somewhere?

Thanks Tim for verifying. That brings us closer to the the issue.

@LyzardKing do you have any idea if there is some kind of Clipboard restriction in Flatpaks and Snaps that could prevent accessing the Clipboard under Wayland?

The snap works (I use it with copy/paste often). There shouldn't be anything flatpak-specific...
I know that the clipboard works differently in wayland, but I'm not sure

I've did some additional testing in my VM:

• AppImage -> Works
• Flatpak -> Works
• Fedore Repo -> Doesn't Work
• Snap -> Doesn't work

I'll try to build tomorrow from source and see how that looks but so far it looks like we need to go in direction Ferdora Repo Packager and Snap packaging and see what's missing there.

• AppImage -> Works
• Flatpak -> Works
• Fedore Repo -> Doesn't Work
• Snap -> Doesn't work

can confirm this.
ksnip-1.7.3-1.fc33.x86_64 its not working :(

i had this bug in F32 too - but i changed from wayland to x11 cause of "such" problems.

I wanted to check how it behaves when build from source but didn't find the time yet, maybe this week.

@LyzardKing you say that you use the clipboard with the snap but have you tried with Wayland? Would be interesting if this was affecting the snap only under Fedora. I also need to figure out who's packaging ksnip for Fedora, it's not me.

I normally run Ubuntu Mate, and it's not wayland compatible yet..
I can try and see if it works on a live ubuntu wayland version

looks like its a permission problem.

just for testing i started ksnip as root. (sudo)
i cant capture something in an area and CAN use it in the clipboard / copy the content to firefox or other programs.

Keep in Mind this permission problem only occurs when using wayland.
i didn't dig deeper yet ...

With Snap and the one from Fedora Repo?

tested with the fedora package. didnt tryed snap / appimage

I have pinged the fedora packager of ksnip, https://fedoraproject.org/wiki/User:Xvitaly. Let's see if has any idea.

Fedora maintainer here.

In Fedora, we force the wayland backend for all Qt applications if the user is using a Wayland session. All other distributions still use xcb (XWayland).

Please try the following:

QT_QPA_PLATFORM=xcb /usr/bin/ksnip

@xvitaly thanks for your feedback. Is this a general thing that you can't access the clipboard under Wayland?

Is this a general thing that you can't access the clipboard under Wayland?

Yes. This is a common, well-known issue between native Wayland and XWayland applications.

Yes. This is a common, well-known issue between native Wayland and XWayland applications.

You mean that Qt Applications are by default XWayland? Or where does the XWayland come from?

You mean that Qt Applications are by default XWayland? Or where does the XWayland come from?

Most of distributions use the xcb backend for Qt applications, but Fedora forces wayland.

If you want to reproduce this issue on other distributions, just run ksnip on Wayland session under the wayland backend:

QT_QPA_PLATFORM=wayland /usr/bin/ksnip

Please try the following:
QT_QPA_PLATFORM=xcb /usr/bin/ksnip

its working with xcb as expected.

I get that most distributions use xcb backend but what I don't understand is why the clipboard works with XWayland and not with Wayland? Where is the error coming from? Is it an issue with the QClipboard or with Wayland? Other Stuff seems to be working with Wayland.

Is there a way to define in the package from the repo that xcb should be used? I would like to avoid forcing users to manually change environment variables.

This would not work when running ksnip from a terminal, right?

Yes of course.

As another workaround, you can simply add to your ~/.bashrc file the following:

export QT_QPA_PLATFORM=xcb

After a system restart, all Qt applications will start using XWayland.

why is it working with the AppImage for you?!

AppImage contains its own Qt build from developer machine. It will not respect system configuration.

We haven't figured out exactly yet.

I understand from this that it's not something that can or should be fixed by ksnip. Thought we can implement workarounds until this issue is resolved, correct?

I suggest to create a desktop action with forcing xcb. I can send a PR.

It's probably a starting point, would be great if you could provide this PR. @LyzardKing would that be enough to fix the snap?

As another workaround, you can simply add to your ~/.bashrc file the following:

Yes, we can add a comment in the readme file. I'm not happy with this solution but currently there doesn't seem to be an alternative.

mayb a ksnip setting where you can select xcb or wayland and ksnip set the variable for the user?

Can we set something like this in a running application? Thing is that if it's a settings, you need to start the application first in order to be able to access the config and at that point it might be to late. I'm open for this option too if there is a way. Maybe setting ksnip own environment variables that we could check for on startup.

I understand from this that it's not something that can or should be fixed by ksnip.

I don't know, sorry. IMHO, this bug should be fixed on Gnome and Qt sides.

Thought we can implement workarounds until this issue is resolved, correct?

Forcing the xcb backend will do more harm than good as it can break some things for other than Gnome 3 desktop environments users.

Maybe setting ksnip own environment variables that we could check for on startup.

The same as patching the desktop file. Will do more harm than good.

Can we set something like this in a running application? Thing is that if it's a settings, you need to start the application first in order to be able to access the config and at that point it might be to late. I'm open for this option too if there is a way. Maybe setting ksnip own environment variables that we could check for on startup.

Another possible option is to check DE, and if it's Gnome running on Wayland, force XCB backend.

I will send a PR.

In the snap the issue is probably a different one, since the QT_QPA_PLATFORM variable is set to gtk3 (on gnome, mate, xfce and other gtk-based distros)

@timrichardson @Frankstar Could one of you test the snap and check the QT_QPA_PLATFORM variable?
After you installed the snap you can run snap run --shell ksnip; env | grep QT_QPA_PLATFORM to print it out

EDIT: the commands have to be separate, so that the second runs in the correct shell instance

• snap run --shell ksnip
• env | grep QT_QPA_PLATFORM

Added workaround in PR #457.

Another possible option is to check DE, and if it's Gnome running on Wayland, force XCB backend.

Don't think that we can this do this check from the application. We do those checks already to determine the correct way for grapping screenshots but at this point Qt hast started already.

Maybe setting ksnip own environment variables that we could check for on startup.

The same as patching the desktop file. Will do more harm than good.

But the every user can decide if he wants to do it or not and then it affects only ksnip. With the desktop file workaround we potentially harm all users but the issue that we are facing here has so far been reported only for Fedora running Wayland. I'm thinking if we should drop the general Workaround and instruct users that are facing this problem to do the fix with env vars for your earlier posts.

Don't think that we can this do this check from the application. We do those checks already to determine the correct way for grapping screenshots but at this point Qt hast started already.

It works if the environment variables are set before the QApplication initialization.

It works if the environment variables are set before the QApplication initialization.

Sorry, saw your PR after my last post. I'm still unsure if I want to go that way because we basically force all Qt applications started after ksnip to use xcb and also for all gnome environments and so far I had only reports about the issue on Fedora.

Currently I think I favor advising users to set those variables manually when they run into this issue and meanwhile trying to push the Qt and gnome side to look into a real fix. First thing would be to find out if this bug was reported upstream and if not, report it.

tested the flatpak and AppImage again.
it works for both.

So i think the best workaround on Fedora is to use the Flatpak or the AppImage.
I dont like advising users to change variables.

+1 for reporting it upstream

also rename the issue pls.
to something like "Can't Copy Image on Fedora with Wayland (emtpy clipboard)"

Copy since the function is named that way.

it has nothing todo with firefox or gmail compose.
we cant post it in any application. (doesnt work for Libre Office, MS Teams, github, ...)

I dont like advising users to change variables.

I'm not a fan of advising users to change variables that could have effect on other applications too but it seems to be like a smaller issue then changing those variables without the user knowing about it. I'll make an entry in the readme stating what we know so far, under known issues. The users can then decide if they want use this workaround or switch to a different binary.

I wont have time today but hopefully over the weekend I will create a minimum example application to show that issue and report that to Qt.

also rename the issue pls.
to something like "Can't Copy Image on Fedora with Wayland (emtpy clipboard)"

Title change to reflect what we know now.

just another thing (for the readme) came into my mind ->
what about just starting it with changed env-variable but not change it system wide?

env QT_QPA_PLATFORM=xcb ksnip
or just:
QT_QPA_PLATFORM=xcb ksnip

this way it only starts ksnip with changed QT_QPA_PLATFORM variable.
Other apps are not affected.

also i just started the flatpak package with
flatpak run --env=QT_QPA_PLATFORM=wayland --socket=wayland org.ksnip.ksnip

and we have the same issue.
so you use xWayland in your flatpak? can you confirm this?

what about just starting it with changed env-variable but not change it system wide?

Good point, I'll mention that. I'll let you known when done so anyone here can provide feedback.

so you use xWayland in your flatpak? can you confirm this?

This is something @LyzardKing can probably answer, he's the flatpak and snap dude :)

oh and before i forget it, Keep in mind it works with sudo privileges.
Maybe also interesting for @xvitaly

sudo "env QT_QPA_PLATFORM=wayland" ksnip

and clipboard is working.
(sure there are other issues / drawbacks -> like a black screen if you capture something, but thats a different story)

So i think the best workaround on Fedora is to use the Flatpak or the AppImage.

Bad advice. I will just apply my workaround #457 in downstream and rebuild Fedora package.

This issue should be fixed in ksnip-1.7.3-2: F32, F33.

Please test these builds.

Installation from Koji on F32:

sudo dnf install https://kojipkgs.fedoraproject.org/packages/ksnip/1.7.3/2.fc32/x86_64/ksnip-1.7.3-2.fc32.x86_64.rpm

Installation from Koji on F33:

sudo dnf install https://kojipkgs.fedoraproject.org/packages/ksnip/1.7.3/2.fc33/x86_64/ksnip-1.7.3-2.fc33.x86_64.rpm

Please test these builds.

works on f33! no errors / problems

Issue reported upstream https://bugreports.qt.io/browse/QTBUG-88293

While testing my minimum example application I've noticed that copying to clipboard works for text but not for images.

ksnip-1.7.3-2 has been pushed to stable. This issue can be closed, I think.

I've left it open until I have updated the readme file, which I have done now. Closing ticket.

According to Qt this issue should be fixed with Qt 5.15.2 version.