Flameshot: Hard hang on saving image with predetermined file path, i3wm

[Jaegrqualm]

Flameshot version

Flameshot v0.6.0-6-g1d7186a
Compiled with Qt 5.11.1

Describe the bug

WM hangs for a good thirty seconds.

To Reproduce

Happens after clicking 'save file' or 'copy to clipboard' on the GUI while using i3wm, when either the -p flag has been passed or when there is a path set up in flameshot.ini. restarting in place allows the system to be used again immediately, but the background for the desktop that flameshot was used on is still frozen until the thirty or so seconds is over. This began happening after some specific system update some months ago.

Expected behavior

It doesn't hang. the above mentioned workaround is all right, but restarting in place can make things wonky, so it's definitely not preferred.

System Information

Arch Linux kernel 4.17.14-arch1-1-ARCH
reasonably up to date

[kdrag0n]

I'm having the same issue after a system upgrade on Arch as well. Window manager is i3, compositor is compton. Kernel 4.17.0-pf6 (linux-pf). However, "Save file" works as expected, just "Copy to clipboard" hangs. I also don't use -p or a predefined path.

I've tried the following solutions to no avail:

• Deleting the entire ~/.config/Dharkael
• Force purging and reinstalling qt5-base, qt5-tools, qt5-svg, and double-conversion
• Package flameshot and AUR package flameshot-git
• Using the prebuilt AppImage for 0.6.0

QT is at 5.11.1. Git version:

Flameshot v0.6.0-6-g1d7186a
Compiled with Qt 5.11.1

[Jaegrqualm]

Alright, I've kept investigating. It appears that things change when you use the keybindings instead of the GUI. Where before if you clicked the button the whole WM would freeze, when you use Ctrl-S it appears to be working as normal. However, the program is still running in the background, still frozen, so if you go to take another screenshot during the same timeframe that your WM would have been frozen, it just won't work. It will pop up after the timeframe is over.

I haven't looked at the code, but this is tempting. It appears that there's some sort of difference with how closing is handled with keybinds vs the GUI.

I have some logs as well, attached, from running flameshot in a terminal before running flameshot gui in another terminal/keybind. It doesn't appear to be debug info beyond Qt/KDE's stuff, and it doesn't appear to vary between WMs, despite the difference in performance.
flameshot.log

[kdrag0n]

Figured out the cause of the issue at last. This happens when you don't have a notification daemon running, as Flameshot tries to send a notification indicating that copying was successful.

After installing and configuring dunst, I no longer get freezes. The notification appears as well.

Why this would be a new issue is beyond me though as I never had problems before without a notification daemon.

[Jaegrqualm]

Yep, that's it. I'm not savvy on any changes notify-send has made lately, but the timeout seems to completely stem from there.
I'm tempted to close this issue, but despite the fact that an external timeout seems to be the culprit, flameshot could definitely handle things more gracefully.

[skykanin]

Having the exact same issue myself. I've tried reinstalling flameshot and flameshot-git. Nothing worked except installing dunst. I'm on kernel version 5.2.21-1-MANJARO using i3wm

[kdrag0n]

You need to run dunst too — it's like every other daemon. If that still doesn't work then I can't help, sorry.

[skykanin]

Oh, I am running dunst and now I'm not having the issue, but I don't really want to be using any notification manager and this wasn't a problem before.

Update: for anyone with a similar problem you can disable notifications in the flameshot settings so at least you don't get a notification

[borgmanJeremy]

We are looking at refactoring the dbus / notification implementation. I'm going to close this as we are trying to de-clutter the issues and this is captured in a couple other issues.