search

flameshot-org / flameshot

Powerful yet simple to use screenshot software :desktop_computer: :camera_flash:
https://flameshot.org
GNU General Public License v3.0
25.04k stars 1.6k forks source link

Flameshot won't copy to clipboard #3501

Open erkange opened 9 months ago

erkange commented 9 months ago

Flameshot Version

v12.1.o

Installation Type

Linux, MacOS, or Windows Package manager (apt, pacman, eopkg, choco, brew, ...)

Operating System type and version

Windows 11 2023H1

Description

Cop and paste doesn't work. unchecking the "Use JPG format" also fixed the issue.

Steps to reproduce

Choose use jpg format for clipboard (PNG Default) take screenshot copy it It will not paste anywehere

Screenshots or screen recordings

No response

System Information

Windows 11

KerradKerridi commented 9 months ago

Have this bug too.

Flameshot v12.1.0 (96c2c82e) Compiled with Qt 5.15.2 winnt: 10.0.19045 windows: 10

mcarlssen commented 8 months ago

Have had this bug for a while - six months at least.

Flameshot v12.1.0 Win10 build 19045.4046, 22H2

Unchecking "Use JPG format for clipboard" resolves issue - seems that PNG enables copy+paste just fine. Switching back to JPG reproduces issue.

Gangelie commented 8 months ago

After an upgrade to Plasma 6 I got these issue to. Changing the setting to "Use JPG format for clipboard" does not help in my case.

freelock commented 8 months ago

I'm also seeing this with Plasma 6 -- I get a notification that it copied to the clipboard, but it's not there when I go to paste it, whatever was previously on the clipboard pastes in.

KDE Plasma 6 on Wayland.

themaxhero commented 8 months ago

Same in here, I'm using NixOS. Everytime I try to copy a selected area, flameshot just closes and nothing goes to my clipboard. I tried to run from the terminal to see if it was logging anything, but no logs at all.

themaxhero commented 8 months ago

Same in here, I'm using NixOS. Everytime I try to copy a selected area, flameshot just closes and nothing goes to my clipboard. I tried to run from the terminal to see if it was logging anything, but no logs at all.

I just found out what I was doing wrong. You need to have flameshot running on the background in order to clipboard work properly.

Gangelie commented 8 months ago

What you mean with running on the background? Mine is running in the taskbar so it should run in background.

untainsYD commented 7 months ago

I do have the same issue, but i don't have any errors running flameshot gui -c -s. It has recently stopped working.

Flameshot runs gui, and when i am trying Ctrl + C to copy to the clipboard, nothing happens.

The strange thing, that i don't have any errors on flameshot gui -c -s, i could find errors only in systemctl xdg

Apr 09 19:10:43 untainsYD-workstation xdg-desktop-por[4615]: Backend call failed: Cannot invoke method; proxy is for the well-known name org.freedesktop.ScreenSaver without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Apr 09 19:10:50 untainsYD-workstation xdg-desktop-por[4615]: Backend call failed: Cannot invoke method; proxy is for the well-known name org.freedesktop.ScreenSaver without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
● xdg-desktop-portal.service - Portal service
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
     Active: active (running) since Tue 2024-04-09 19:14:50 EEST; 15min ago
   Main PID: 41774 (xdg-desktop-por)
      Tasks: 6 (limit: 19027)
     Memory: 3.5M (peak: 4.4M)
        CPU: 51ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/xdg-desktop-portal.service
             └─41774 /usr/lib/xdg-desktop-portal

Apr 09 19:14:50 untainsYD-workstation systemd[2129]: Starting Portal service...
Apr 09 19:14:50 untainsYD-workstation xdg-desktop-por[41774]: Choosing wlr.portal for org.freedesktop.impl.portal.ScreenCast via the deprecated UseIn key
Apr 09 19:14:50 untainsYD-workstation xdg-desktop-por[41774]: The preferred method to match portal implementations to desktop environments is to use the portals.conf(5) configuration file
Apr 09 19:14:50 untainsYD-workstation systemd[2129]: Started Portal service.
> dbus-monitor --session sender=org.flameshot.Flameshot
signal time=1712680273.345332 sender=org.freedesktop.DBus -> destination=:1.172 serial=4294967295 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.172"
signal time=1712680273.345361 sender=org.freedesktop.DBus -> destination=:1.172 serial=4294967295 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.172"
method call time=1712680276.242272 sender=:1.106 -> destination=org.freedesktop.DBus serial=120 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.freedesktop.Notifications'"
method call time=1712680276.242354 sender=:1.106 -> destination=org.freedesktop.DBus serial=121 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.Notifications"
method call time=1712680276.242643 sender=:1.106 -> destination=org.freedesktop.Notifications serial=122 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
   string "flameshot"
   uint32 0
   string "flameshot"
   string "Flameshot Info"
   string "Capture saved to clipboard."
   array [
   ]
   array [
   ]
   int32 5000
method call time=1712680276.290658 sender=:1.106 -> destination=org.freedesktop.DBus serial=123 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.freedesktop.Notifications'"
method return time=1712680276.322690 sender=:1.106 -> destination=:1.173 serial=124 reply_serial=32

I am using arch linux (latest), Wayland, SwayWM.

It's very strange, but when i am clicking on a tray, then it works with the clipboard fine. I am running it in sway conf like deamon.

exec_always {
    'pkill $printscreen; sleep 1; $printscreen &'
}

and invoke it on the hotkey like bindsym --no-repeat Print exec flameshot gui.

insunaa commented 6 months ago

Flameshot always makes a blocking call asking for a notifications daemon (even if notifications are disabled in config/settings). This call blocks for 10-20 seconds in my experience and only after it has returned unsuccessfully is the screenshot actually put into the clipboard buffer. A workaround for this is to enable a simple Notifications daemon like dunst

Ultimately the fix would be to make the call to the notification daemon non-block/async or optional entirely.

Edit: Having checked the code it seems that sendMessage should abort when the config is set to false, so I'm guessing the actual thing that's blocking here is

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

this is called when flameshot is initialized, so it will only block if you don't run the flameshot daemon but start a new instance of flameshot for every screenshot. Might explain why screenshotting from tray works while screenshotting from shortcut does not.

Edit 2: https://bugreports.qt.io/browse/QTBUG-14485?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aworklog-tabpanel

Relevant bug for QT upstream.

I'm not sure how to initialize the QDBusInterface asynchronously, or if that even makes sense. But maybe it makes sense to just not initialize it at all if the config already disables sending Notifications anyway.

Edit3: OK nvm, while my point stands there is also an additional issue that really does prevent copying to clipboard, even when I specifically added some code to circumvent the QDBusInterface initialization. That resolved the blocking issue, but the systemd log output says the screenshot has been copied to clipboard, while actually the clipboard has been cleared.

Edit4: Edit3 was fake news. It didn't work for me because I didn't use -DUSE_WAYLAND_CLIPBOARD=1 in cmake. When I use that things work exactly as expected.

diff --git a/src/utils/systemnotification.cpp b/src/utils/systemnotification.cpp
index 903bf4cd..d4bf8e4e 100644
--- a/src/utils/systemnotification.cpp
+++ b/src/utils/systemnotification.cpp
@@ -24,6 +24,9 @@ SystemNotification::SystemNotification(QObject* parent)
   , m_interface(nullptr)
 {
 #if !(defined(Q_OS_MACOS) || defined(Q_OS_WIN))
+    if (!ConfigHandler().showDesktopNotification()) {
+        return;
+    }
     m_interface =
       new QDBusInterface(QStringLiteral("org.freedesktop.Notifications"),
                          QStringLiteral("/org/freedesktop/Notifications"),

Edit5: Oops, posted all of this in the Windows 11 issue instead of the Linux issues. My bad

Edit6: @erkange If you can try to compile flameshot on Windows, try to apply this patch and see if it solves the problem for you

diff --git a/src/utils/screenshotsaver.cpp b/src/utils/screenshotsaver.cpp
index f7f5a710..f9a2db72 100644
--- a/src/utils/screenshotsaver.cpp
+++ b/src/utils/screenshotsaver.cpp
@@ -163,7 +163,7 @@ void saveToClipboard(const QPixmap& capture)
             QApplication::clipboard()->setPixmap(capture);
         }
 #else
-        QApplication::clipboard()->setPixmap(capture);
+        saveToClipboardMime(capture, "png");
 #endif
     }
 }
untainsYD commented 6 months ago

This call blocks for 10-20 seconds in my experience and only after it has returned unsuccessfully is the screenshot actually put into the clipboard buffer. A workaround for this is to enable a simple Notifications daemon like dunst

for example, i have a notification daemon already, and it is a mako, but the issue still occurs

insunaa commented 6 months ago

@untainsYD Which distro are you using? In addition to needing a dbus notification daemon (that's already running) flameshot also needs to be compiled with -DUSE_WAYLAND_CLIPBOARD=1 This is default on Arch, but I don't know if it is in Flatpak or on other Distros

untainsYD commented 6 months ago

@untainsYD Which distro are you using? In addition to needing a dbus notification daemon (that's already running) flameshot also needs to be compiled with -DUSE_WAYLAND_CLIPBOARD=1 This is default on Arch, but I don't know if it is in Flatpak or on other Distros

I am using arch, and a flameshot from extra repo.

untainsYD commented 1 month ago

@mmahmoudian we are seeking your help, this issue has not been fixed, but even some PR was made a time ago, it's a very annoying issue

mmahmoudian commented 1 month ago

@untainsYD Thanks for your comment and concern, but I don't have the liberty to merge PRs with large code changes. When I joined the project, I accepted to do community management and triage, and that's what I have been doing. This is because I'm not and experienced C++ developer and it would be better if experienced devs weigh in and check the code. We have been asking people to join the dev team to reduce the work load and proceed faster, but in the past year, no one volunteered. Therefore, it is what it is. This project is opensource and is from the community for the community, and we need the community to step up and and give us a hand.

These said, you are on Arch, and the AUR is maintained by us (it follows the HEAD of the master branch of this git repo. Therefore you can use the AUR instead and get some of the fixes that have been merged already and are queued for V13.0.0:

https://github.com/flameshot-org/flameshot/milestone/7?closed=1