Flameshot won't copy to clipboard

nicolascmsp commented 5 years ago

Flameshot version Flameshot 0.6.0+git20191001-1(Debian) Compiled with Qt 5.11.3

Describe the bug Image does not go to clipboard copy after pressing copy combination

To Reproduce When i hit print screen button, and select area, and after i click ctrl+c - and the app say messages with the image has copy, but when i press ctrl+v, doesn't paste the image

Expected behavior I would like the image to actually be copied to the clipboard and then I will paste it.

System Information 5.2.0-kali3-amd64

hosiet commented 5 years ago

There's a lot of missing information. Specifically:

What kind of Desktop Environment are you using? Does it have a clipboard manager?
Is the D-Bus facilities on your system working well?
In which software are you pasting the image? (GIMP, web browser, ...)

Please consider providing those information. Thanks!

jarda-wien commented 5 years ago

I am observing the same issue on Archlinux with all current updates. No desktop environment (using i3-wm).

Flameshot was working flawlessly before with this setup, not sure which package upgrade broke it.

The issue is that the copy to clipboard button doesn't do anything. In fact, after clicking it, nothing happens (the screen portion selection is up) and no other Flameshot button reacts to anything.

Attached is an strace log and the coresponding console below (the segfault is after sending SIGKILL):

strace -o /tmp/flameshot.log flameshot 
qt5ct: using qt5ct plugin
qt5ct: D-Bus system tray: no
qt5ct: custom style sheet is disabled
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::setCompositionMode: Painter not active
QPainter::translate: Painter not active
QPainter::setPen: Painter not active
QPainter::setBrush: Painter not active
QPainter::setBrush: Painter not active
Segmentation fault (core dumped)

flameshot.log

jarda-wien commented 5 years ago

Just FYI, looking for a quick replacement, screengrab seems to behave exactly the same -> copy to clipboard freezes the app. Something is broken in the system.

werman commented 5 years ago

I have the same issue as @jarda-wien. I found that it was caused by lack of org.freedesktop.Notifications dbus service (try notify-send 'test' in terminal).

You can manually add it - see https://wiki.archlinux.org/index.php/Desktop_notifications#Standalone

Flameshot is being stuck in src/utils/systemnotification.cpp:20 on QDBusInterface creation:

    m_interface = new QDBusInterface(QStringLiteral("org.freedesktop.Notifications"),
                                     QStringLiteral("/org/freedesktop/Notifications"),
                                     QStringLiteral("org.freedesktop.Notifications"),
                                     QDBusConnection::sessionBus(),
                                     this);

I don't know why it hangs, the documentation for QDBusInterface states:

If the remote service service is not present or if an error occurs trying to obtain the description of the remote interface interface, the object created will not be valid (see isValid()).

So it should just be invalid.

There is a known issue with QDBusInterface - https://bugreports.qt.io/browse/QTBUG-75016 but I don't think it's applicable here.

nicolascmsp commented 5 years ago

Information is not missing here, in fact it is not requested here on the start.

You speak like a person who handles a lot of the subject, very different from the person I am.

I am the person who uses this tool because they like it and because they want to see their progress, regardless of any mistake, other than that, paid for some software to serve me as expected.

As I believe that is not the case, some friends of mine here have been able to show in their terms what problems I have, and to allude what we are talking about, I have been researching what is D-BUS and I have no idea how you You may think I know that. But to answer you, it is working yes, other applications they work normally with it. One of them is the system's own copy and paste tool.

And no, I don't use copy systems, even download an addons, which creates an affordable copy system history, but still, the tool doesn't work as expected.

I am using a newly installed Linux, with no application running behind it.

Just enter what type of log you need, being a little clear, I'll provide you with no problem.

Thanks for listening

stumyp commented 5 years ago

Same situation here.

OS: Debian testing package: flameshot 0.6.0+git20191001-1 DE: KDE

flameshot gui starts, and shows the controls, after final action and copy to clipboard, there nothing copied to the clipboard. I am using copyq to manage and see contents of my clipboard.

Once I rolled back to the previous version (http://cloudfront.debian.net/debian/pool/main/f/flameshot/flameshot_0.6.0-11_amd64.deb) everything works just fine.

And yes, D-bus has no problems, I check contents of the clipboard with copyq.

stumyp commented 5 years ago

I have similar system, same OS/DE/version and everything works fine.

What would you need to debug and how can I help?

up-to-you commented 5 years ago

Exactly the same issue! Ubuntu 19.10, kernel: 5.3. Current commit: 91ba28c3ded7ca3314f02418761c982069cf8b33

Author: Boyuan Yang byang@debian.org Date: Tue Oct 1 14:25:05 2019 -0400

translations: Refresh Simplified Chinese (zh_CN) translation (#579)

up-to-you commented 5 years ago

The bug is mostly related to "Close after capture" option. Without this option everything works fine. But for the previous version of an app this option didn't clear the clipboard.

ipkpjersi commented 5 years ago

I am able to reproduce this bug on Ubuntu 18.04 with Xfce 4.12 and using flameshot version 0.6.0, only with the flameshot screen -c which does not display the notification. However, right clicking the gui and clicking "Take Screenshot" which opens up the region select window does copy the screenshot to the clipboard and does pop up the notification that it has been copied to the clipboard.

avila commented 4 years ago

I am affected/able to reproduce this bug in Ubuntu 19.10 with Gnome 3.34.1

Flameshot 0.6.0+git20190714-1(Debian)
Compiled with Qt 5.12.4
I am able also not able to automatically save to a location using the -p flag.
The only way I am able to retrieve the screenshot is by clicking at the little diskette and manually saving it somewhere.
I am not sure how to check if "-Bus facilities on your system working well", but I have not encountered any problem with copying and pasting with other applications.

Please, let me know if I could provide more detailed information. (btw, I also tried the snap version, but it has some other problems related to GTK / Qt modules.)

jarda-wien commented 4 years ago

This somehow seems to be related to the notification daemon stuff. I didn't have one originally and noticed some other applications failing lately. Most probably due to some change in a system library used by all those GUI applications.

As mentioned by @werman notify-send 'hi' didn't do anything. It never did really since I haven't had desktop notifications since moving to i3-wm several years ago.

All was resolved by installing dunst (other options are listed in the archlinux wiki) and starting the daemon with systemctl --user start dunst.service. Flameshot copy to clipboard started working giving me the notification Flameshot Info Capture saved to clipboard.

alparViniciusLeite commented 4 years ago

In Fedora 31, it does not copy to the clipboard. I am using CTRL + C, OR ENTER, OR COPY TO CLIPBOARD icon, but it doesn't work. The notification that was copied appears, but when using CTRL + V, there is no content.

Flameshot v0.6.0 Compiled with Qt 5.12.4

avila commented 4 years ago

As mentioned by @werman notify-send 'hi' didn't do anything. It never did really since I haven't had desktop notifications since moving to i3-wm several years ago.

I am not sure what you mean... but here notify-send 'hi' works as expected. And as @alparViniciusLeite said, the notification appears sayind that the content was copied to the clipboard...

If I use the built-in (ubuntu) screenshot tool, the button "copy to clipboard" works as exptected.

I there is something I can try on my side, please let me know...

avila commented 4 years ago

btw: I can confirm that rolling back to a previous version, as pointed out by @stumyp, works as expected...

trevorkirpaul commented 4 years ago

FWIW: I'm having this issue on Fedora 31 Wayland but if I switch to xorg then the image is stored on the clipboard and I am able to use the feature.

I upgraded to Fedora 31 earlier today and flameshot was working as intended on Fedora 30 (up to date packages of course).

After attempting to use flameshot and selecting the "copy to clipboard" option, the previous entity in my clipboard is cleared but the image does not replace it. It would appear that nothing replaces the previous item.

Hopefully this information helps!

Version: Flameshot v0.6.0 Version2: Compiled with Qt 5.12.4 Distro: Fedora 31 DE: GNOME 3.34.1 clipboard manager: no Pasting into: Discord (flatpak), Chrome (haven't tried anything else)

specs from wayland with clipboard issue

EDIT: Possibly related to `Qt` version?

I have another computer with Fedora 31 and I realized that I never had an issue with flameshot on it. When using the 'copy to clipboard' feature with the following version, it works as intended:

Flameshot v0.6.0
Compiled with Qt 5.12.1

It would appear that Qt is the difference here.

brunofontes commented 4 years ago

Hi, everyone,

I have the same issue on Manjaro 18.1.3. It only happens when using the Close after capture option, otherwise it works normally.

System: Kernel 5.3.12-1 KDE 5.64.0 / Plasma 5.17.3 Qt 5.13.2 Flameshot v0.6.0-70-g91ba28c

Oh, I am using X11, not Wayland. :)

avila commented 4 years ago

I have the same issue on Manjaro 18.1.3. It only happens when using the Close after capture option, otherwise it works normally.

true... if i disable the close after capture option, it works fine here (ubuntu 19.10 gnome) as well!

maybe what I said before, that rolling back to a previous verions fixed the problem, was rather because of the option that was disabled after rolling back...

in any case, the problem seems to be related to the *close after capture option

abhijeetviswa commented 4 years ago

I can reproduce the problem as well.

Flameshot: 0.6.0+git20190714-1(Debian) Compiled with Qt 5.12.4

Distro + DE: Ubuntu + Gnome Gnome: 3.34.1 Clipboard Manager: I use the Clipboard Indicator extension for Gnome. Pasting into: Firefox (haven't tried anything else)

Disabling close after capture fixes the problem for me as well.

jinliming2 commented 4 years ago

Same Here. OS: Gentoo Kernel 5.4.18 Flameshot: build from source with git commit id: 91ba28c3ded7ca3314f02418761c982069cf8b33 Compiled with Qt 5.13.2 No desktop environment, just i3 window manager.

Seems like screenshot image in the clipboard will be removed after flameshot closed. I disabled close after capture, copy the selection into the clipboard will set clipboard content.

$ xclip -selection clipboard -t TARGETS -o
application/x-qt-image
image/png
image/bmp
image/cur
image/ico
image/pbm
BITMAP
image/pgm
image/ppm
PIXMAP
image/xbm
image/xpm
TARGETS
MULTIPLE
TIMESTAMP
SAVE_TARGETS

But after I close flameshot through the tray icon, my clipboard will be empty.

$ xclip -selection clipboard -t TARGETS -o
Error: target TARGETS not available

gaptastic commented 4 years ago

Using @jinliming2 comments, I updated flameshot to not close after screenshot using 'flameshot config'. While not ideal it's a good enough work around for me!

stanfieldr commented 4 years ago

I confirmed on Fedora 31 copy to clipboard does not work on Wayland, but does work on X11

chung1905 commented 4 years ago

Should we open another ticket for clipboard on Wayland? Since it's seems not the same issue with this ticket?

I confirm Arch Linux copy to clipboard doesn't work on Wayland:

Flameshot v0.6.0
Compiled with Qt 5.14.1

The success notification appear, clipboard is emptied (the old one is cleared).

Works very well on X11.

woody34 commented 4 years ago

I suspect #722 may resolve this issue. :crossed_fingers:

MrSunshyne commented 4 years ago

I confirm that disabling "Save after capture" resolved the issue for me.

Image pasted using flameshot

cvincent commented 4 years ago

I was having this problem and suspected it was due to the "Close after capture" option. It seems X11's clipboard loses track of what you copied if the app you copied from was closed, which I've noticed before in other situations. Sure enough, disabling "Close after capture" did it. Not sure if this happens with full-fledged DEs such as GNOME.

alparViniciusLeite commented 4 years ago

I use Fedora 31 and installed it with "sudo dnf install flameshot". I checked the configuration options and it has just this:

MrSunshyne commented 4 years ago

@cvincent I can confirm, I had the issue in GNOME.

koutsenko commented 4 years ago

Same issue here, Ubuntu 20, KDE.

avindra commented 4 years ago

@lupoDharkael Is there any chance you can cut a new release?

The new config option that reportedly fixes this issue is only on master, so distributions like openSUSE and Fedora are lagging behind as they are only using the latest tagged release.

abrahaobittar commented 4 years ago

I've facing the same problem with fedora 31/32. What i discover is: when i use x11 the image goes to clipboard, works fine. When i use wayland i face the same issue, the image dont' copy to clipbord (ive tested on webbrowser, gimp and libre writer).

Gowee commented 4 years ago

Flameshot v0.6.0-70-g91ba28c
Compiled with Qt 5.13.1

GNOME 3.36.3 with Wayland
Arch Linux with kernel 5.7.7-zen1-1-zen

When I click the Copy button and try to paste into Firefox with Ctrl+V, nothing appears. However, it does work in Telegram, where the pasted picture is distorted, though:

The (nearly) same region taken by GNOME Screenshot: gnome-screenshoot .

hellenictechnologies commented 4 years ago

previous version works great with Copying

curl -OL http://cloudfront.debian.net/debian/pool/main/f/flameshot/flameshot_0.6.0-11_amd64.deb sudo dpkg -i flameshot_0.6.0-11_amd64.deb flameshot gui (enjoy your CTRL+C working again! )

Same situation here.

OS: Debian testing package: flameshot 0.6.0+git20191001-1 DE: KDE

flameshot gui starts, and shows the controls, after final action and copy to clipboard, there nothing copied to the clipboard. I am using copyq to manage and see contents of my clipboard.

Once I rolled back to the previous version (http://cloudfront.debian.net/debian/pool/main/f/flameshot/flameshot_0.6.0-11_amd64.deb) everything works just fine.

And yes, D-bus has no problems, I check contents of the clipboard with copyq.

Jonbeckas commented 4 years ago

previous version works great with Copying

curl -OL http://cloudfront.debian.net/debian/pool/main/f/flameshot/flameshot_0.6.0-11_amd64.deb sudo dpkg -i flameshot_0.6.0-11_amd64.deb flameshot gui (enjoy your CTRL+C working again! )

Same situation here. OS: Debian testing package: flameshot 0.6.0+git20191001-1 DE: KDE flameshot gui starts, and shows the controls, after final action and copy to clipboard, there nothing copied to the clipboard. I am using copyq to manage and see contents of my clipboard. Once I rolled back to the previous version (http://cloudfront.debian.net/debian/pool/main/f/flameshot/flameshot_0.6.0-11_amd64.deb) everything works just fine. And yes, D-bus has no problems, I check contents of the clipboard with copyq.

Thank you for the workaround, works fine for me.

Killea commented 4 years ago

The bug is mostly related to "Close after capture" option. Without this option everything works fine. But for the previous version of an app this option didn't clear the clipboard.

This is really helpful.

tymokvo commented 4 years ago

Reproduced on fedora 32. Not working under Wayland, does work under X11.

oliveiraped commented 4 years ago

HI Same Problem with Ubuntu 20.04 Focal, solved the issue by setting the following settings :

RememberTheAir commented 4 years ago

I have the same issue on Pop!_OS 20.04 LTS (using Gnome 3.36.3) and X11 as ws

Disabling "close after capture" works as a workaround

mmahmoudian commented 4 years ago

Since the 0.8 has squished many bugs, I suggest you test the version 0.8 and comment here if the issue persists. Otherwise I will close this issue in 14 days in favor of 0.8

avindra commented 4 years ago

Retested with 0.8 and it's still an issue. The notify daemon must be running, otherwise flameshot hangs. (If you're using dunst and systemd, see a solution for starting the daemon.

I imagine this may be fixed by implementing a timeout or some kind of check here, rather than assuming org.freedesktop.Notifications will be available. https://github.com/flameshot-org/flameshot/blob/master/src/utils/systemnotification.cpp#L18-L23

mmahmoudian commented 4 years ago

@avindra few points:

are you sure you are responding to the correct thread? As far as I understand, so far everyone in yhis thread narrowed it down to wayland and thr initial complain was about not being able to copy. What you are stating is that the notification daemon should be running otherwise Flameshot crashes.
The latest release of Flameshot is 0.8.3: https://github.com/flameshot-org/flameshot/releases/tag/v0.8.3

jarda-wien commented 4 years ago

@avindra few points:

1. are you sure you are responding to the correct thread? As far as I understand, so far everyone in yhis thread narrowed it down to wayland and thr initial complain was about not being able to copy. What you are stating is that the notification daemon should be running otherwise Flameshot crashes.

2. The latest release of Flameshot is 0.8.3:
   https://github.com/flameshot-org/flameshot/releases/tag/v0.8.3

@mmahmoudian I am not using wayland and a missing notifications daemon was a cause of the issue for me. See up there.

mmahmoudian commented 4 years ago

@borgmanJeremy Can you confirm that Flameshot is dependent on notification daemon?

borgmanJeremy commented 4 years ago

There is a default timeout in the notification. I believe it is 30 seconds. A notification daemon is required.

mmahmoudian commented 4 years ago

@borgmanJeremy considering that the notification is not critical for functionality of Flameshot, I suggest making Flameshot to work even when the notification daemon doesn't exist.

owiofwm2i commented 4 years ago

The bug is mostly related to "Close after capture" option. Without this option everything works fine. But for the previous version of an app this option didn't clear the clipboard. tks

mmahmoudian commented 4 years ago

@borgmanJeremy considering that the faith of the "close after capture" is decided, should we close this issue?

hparlak commented 3 years ago

I just installed flameshot on Fedora 33. Same problem. v.0.8.5 "close after capture" has no effect on the problem. It never copies to clipboard, although shows a notification saying that it did. I'm currently using the option "open capture in app" option to open the image in standard image viewer and then copy to clipboard, which is not that hard, but is absurd of course.

mmahmoudian commented 3 years ago

@hparlak Please provide us the following:

which Display Server Protocol are you using (Xorg or Wayland)
what Desktop Environment are you using (Gnome, KDE, ...)
your Flameshot config file (cat .config/flameshot/flameshot.ini)

You can use the following page if you don't know how to extract these info from your system: https://flameshot.org/guide/issue-reporting/

hparlak commented 3 years ago

Flameshot v0.8.5 Compiled with Qt 5.15.1

wayland

buttons=@Variant(\0\0\0\x7f\0\0\0\vQList\0\0\0\0\x14\0\0\0\0\0\0\0\x1\0\0\0\x2\0\0\0\x3\0\0\0\x4\0\0\0\x5\0\0\0\x6\0\0\0\x12\0\0\0\xf\0\0\0\x13\0\0\0\a\0\0\0\b\0\0\0\t\0\0\0\x10\0\0\0\n\0\0\0\v\0\0\0\f\0\0\0\r\0\0\0\xe\0\0\0\x11) closeAfterScreenshot=false disabledTrayIcon=false drawColor=#ff0000 drawThickness=0 saveAfterCopy=false saveAfterCopyPath=/home/aparlak/Pictures savePath=/home/aparlak/Pictures showDesktopNotification=true showHelp=true showSidePanelButton=true startupLaunch=true

I tried turning on/off the following: Save image after copy, close after capture, Show desktop notifications. None helped.

Thanks for helping

On 23/11/2020 15:17, Mehrad Mahmoudian wrote:

@hparlak https://github.com/hparlak Please provide us the following:

which Display Server Protocol are you using (Xorg or Wayland)

what Desktop Environment are you using (Gnome, KDE, ...)

your Flameshot config file (|cat .config/flameshot/flameshot.ini|)

You can use the following page if you don't know how to extract these info from your system: https://flameshot.org/issue-reporting/ https://flameshot.org/issue-reporting/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/flameshot-org/flameshot/issues/635#issuecomment-732126856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR3QEIO6ZX2GU3VXDRYZ2C3SRJHHNANCNFSM4JBOCJVA.

-- arto_signature ileri civatacilik logo Arto Parlak İleri Civatacılık Sanayi ve Ticaret Ltd. Şti. Tel: +90 212 2433700 http://www.ilericivata.com http://www.ilericivata.com Tersane Cad. 65 Karaköy Beyoğlu İstanbul

flameshot-org / flameshot