Bug 413571

Summary:	Export -> <app> stores screenshot persistently to save location
Product:	[Applications] Spectacle	Reporter:	grmat
Component:	General	Assignee:	Boudhayan Gupta <me>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	kde, nate
Priority:	NOR
Version First Reported In:	19.08.2
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description grmat 2019-10-28 22:44:40 UTC

SUMMARY
When using the export function to open the screenshot in another app, it is saved persistently to the configured "save location".

STEPS TO REPRODUCE
1. Take screenshot with spectacle
2. Click export -> select another application

OBSERVED RESULT
Screenshot is persistently saved to configured "Save location"

EXPECTED RESULT
Screenshot is shared via clipboard or temporary file

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 5.17.1
KDE Frameworks Version: 5.63.0
Qt Version: 5.13.1

ADDITIONAL INFORMATION
This is a change in behaviour. Earlier versions of spectacle didn't do this.

The behaviour is also not clear to the user. "Export" and "Save" are two different actions, labeled with two different icons.
The "Save Location" is set in the "Save" tab. There is no hint, neither in text nor in icons that this location is applied to the "Export" function as well.

I also think those functions are analogous to a web browser's download functions "open with" vs. "save to". The first stores the file in /tmp and opens it with a selected program, the last saves to a given path. I'm quite sure that's what people expect from Export/Save in Spectacle as well.

Comment 1 Nate Graham 2019-10-29 21:26:46 UTC

Yeah, this is deliberate. It's the solution to a set of even worse problems we had before when we saved the screenshot to /tmp and had the external app open it from there. The problem was that after users edited the image in the external app and then saved and quit, the image would seem like it was just gone (and from the user's perspective, it was). Also on some systems, the permissions in /tmp differed from the permissions in the user's homedir such that trying to save or save as would fail, making the user want to throw their computer out the window and hunt down the developers with pitchforks and torches. :)

See Bug 399395 and its multiple duplicates for details.