Flameshot: Cannot copy to clipboard when open "Close after capture" option

[BlindingDark]

Flameshot version
234a51b

Describe the bug
Cannot copy to clipboard when open "Close after capture" option.
I also the notification is not displayed correctly.(is blank) Usually it will prompt that it has been successfully copied to the clipboard.

I guess it is too early to exit, maybe can add a little delay before exiting.
But it works fine on my other computer.

Similar issue
https://github.com/lupoDharkael/flameshot/issues/530

To Reproduce
open "Close after capture" option.
See if the screenshot is copied to the clipboard.

System Information
Manjaro 18.0.4
KDE 5.59.0 / Plasma 5.15.5

[JurisMajors]

If you have xclip, I made a patch to optionally save it to xclip clipboard, instead of the clipboard that is in the instance of flameshot. So, after closing flameshot, the picture would still be on your clipboard. See PR #559

[lufterc]

I run flameshot using this shell command: flameshot gui -r | xclip -selection clipboard -t image/png (-r for stdout output mode), it works fine.

But the current implementation of "Close after capture" option is pretty messy IMO because 'Copy to clipboard' button doesn't work properly (flameshot quits and clipboard gets lost). I think it should stay in background until clipboard isn't overwritten and quit only after that, so the proper implementation may not be trivial.

[FeryET]

I have the same issue in Lubuntu 19.10. Any update on this?

This is the output of Flameshot -v:

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

[hosiet]

It's the characteristic of X Clipboard: there must be a running process left on the system holding the clipboard contents. If it's terminated (like the "Close after Capture" option here), the content will be lost.

Using "xclip" only circumvents but does not solve this problem: it's just the content holder is converted from flameshot to xclip. Users of xclip can take a try and you will surely notice that a xclip process will be keep running until the clipboard is filled with other contents. In this sense, the "Close After Capture" idea is fundamentally broken: you must keep something running and cannot completely "close".

If we are not to depend on an extra external tool (xclip), maybe we can spawn a tiny process after a capture is taken with "close after capture" enabled, holding the content for clipboard use. This would essentially be a reimplementation of xclip's core function.

[borgmanJeremy]

@hosiet My recommendation is we document this behavior and recommend installation of xclip. This way we are not re-implementing xclip. Additionally users can enable auto saving rather than copying to clipboard when using close after capture.

If you and @mmahmoudian agree I will updated the readme and close issues related to this.

[hosiet]

I am okay with it. However in order for xclip to be working, we need some more tweaks with flameshot source code (so that flameshot can make use of external xclip).

Otherwise if we do not want to touch the code in freeze, it might be better to document that such feature does not work with 0.8.x series.