Flameshot version
v0.8.5+git10.376a6f2
Describe the bug
If clicking on save image inside the snap installed via Ubuntu Snap Store always saves the screenshot to "/run/user/1000/XXXX". It doesn't matter if you change the location to save to in configuration or start from command line with -p
!! Everything works quite fine with installing flameshot via "apt install flameshot".""
To Reproduce
Install Flameshot snap via Ubuntu snap store.
Expected behavior
Save to home folder or custom path.
System Information
Linux 5.4.0-52-generic #57~18.04.1-Ubuntu
Not able to replicate this on Kubuntu 20.04, I'll try in a gnome VM and report back.
Able to replicate it on Ubuntu 20.04 + gnome. Thanks for reporting.
@cerobotics Can you post the contents of your flameshot config? It's located at ~/.config/flameshot
If you see the /run/user/<> in that file delete it and try again.
Hey, there is no config inside ~/.config/flameshot.
There is a config file under: ~/snap/flameshot/6/.config/flamshot/flameshot.ini with the following content:
[General]
disabledTrayIcon=false
drawColor=#ff0000
drawThickness=0
saveAfterCopyPath=/home/
savePath=/run/user/1000/doc/1760920b
When I delete the savePath param and restart it gets rebuild automatically (with different run id).
I am also experiencing the same issue; reproducible as @cerobotics described.
I'm using ubuntu 20.04, gnome; X11, Linux 5.4.0-52-generic #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Likewise, there is no directory at ~/.config/flameshot; only at ~/snap/flameshot/6/.config/flamshot/flameshot.ini
I've tried to export my configuration through flameshot's gui but receive the message 'unable to save file' in my home directory even though I did verify that through the 'software install' and snap that the access to home folder is on.
my infi file:
[General]
disabledTrayIcon=false
drawColor=#800000
drawThickness=0
savePath=/run/user/1000/doc/4ce1be
When you get the save dialog, can you try adding .png to the file name? That seems to fix it for me, still going to find the root cause and patch it, but that might be a good first step.
@borgmanJeremy Thanks for your effort; I was able to save the screenshot in my home directory after adding the .png extension
Thanks for confirming! That means I am on the right track here. I will leave this issue open until we fix the root cause.
Okay the root cause is the interaction between gnome file manager and Qt's QFileDialog. If I used a Qt file prompt instead of the native dialog box, this issue (and other issues) go away. Here is a similar issue from another project: https://github.com/OPM/ResInsight/issues/6345
Unfortunately this means I need to disable the native dialogs for file saving which makes the theme ugly.
I have this issue as well
I am also experiencing this same issue with some slight differences:
Flameshot version
v0.8.5+git10.376a6f2
System Information
Kernel: 4.15.0-112-generic
OS: Ubuntu 18.04.5 LTS
Details
Similar to above, choose to save the screenshot in a specific folder, give the file a name. However a message is displayed (via dunst) that the file was actually saved to /run/user/1000/XXXX where XXXX is a unique string per save.
The differences to the above though are that:
/run/user/1000/doc/by-app/snap.flameshot/XXXX/Other info
Noticed that your site on Snapcraft.io links to a non-existing page -> https://flameshot.js.org/
Thanks for an awesome tool.
@gjcooper Are you using gnome?
Also thanks for pointing out the link issue, I'll fix that tonight. I'm working the the permanant fix for the path, but taking extra time to refactor this portion of the code and write some tests.
@gjcooper Are you using gnome?
Kind of, my system was based on standard 18.04 Ubuntu (ie Gnome) - however day to day I generally run with the i3 window manager.
At the point of this writing, if I install and use the Ubuntu 18.04 snap package, this exact thing happens. It doesn't save in the folder I specify but in /run/user/1000......
If I use the Aptitude package manager provided version "Flameshot 0.5.1-1(Debian)" of flameshot, everything works as expected.