| Summary: | Make it possible to cancel taking a screenshot | ||
|---|---|---|---|
| Product: | [Unmaintained] ksnapshot | Reporter: | Michał Kosmulski <michal> |
| Component: | general | Assignee: | Richard Moore <rich> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | arthur, bluedzins, zhx |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Slackware | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Michał Kosmulski
2006-06-15 17:11:49 UTC
What is the problem with saving all the snapshots? Diskspace is cheap, memory isn't. If you have a good answer to this, then reopen the bug, but for now I'm going to close it as I think the current behaviour is better for most users. Thanks for the feedback. Rich. Sorry if I was not clear enough, I'll try to re-explain my idea since I think I was misunderstood. As for "Diskspace is cheap, memory isn't": I wasn't suggesting that all snapshots should be kept in memory or anything like that. What I wanted to suggest would be to keep just one snapshot in memory, same way as now, but to allow cancelling a snapshot. My idea is to introduce some keyboard shortcut (say alt-esc or something similar) which would enable the user to not take the snapshot after they clicked 'New snapshot'. Here's an illustration of my idea. What we have now: 1. user takes nice snapshot A but forgets or doesn't have time to save 2. user clicks 'New snapshot' and waits for a more interesting image to appear in their application 3. user realizes that snapshot A is much better than everything seen on screen afterwards and wants to keep snapshot A 4. user can't cancel taking the snapshot after 'New snapshot' is clicked so the only thing they can do is to click the mouse at some random moment, taking snapshot B and thus destroying snapshot A What I was suggesting: 1. [same as above] user takes nice snapshot A but forgets or doesn't have time to save 2. [same as above] user clicks 'New snapshot' and waits for a more interesting image to appear in their application 3. [same as above] user realizes that snapshot A is much better than everything seen on screen afterwards and wants to keep snapshot A 4. user presses alt-esc, which causes the KSnapshot window to reappear, displaying snapshot A. User doesn't lose that image and can save now. So, the only modification to current behavior would be adding that magic key combination which cancels taking the screenshot and returns to the previously taken one. The main problem with saving all images is that even clicking the Save button and just blindly pressing enter (the auto numbering feature is nice in that you can just press enter and not worry about the filename) takes a second or two as well as several key strikes. Sometimes (especially when dealing with animation) it's hard to get the right snapshot the first time and you don't really know which one is going to be best. So you just want to take a snapshot and then wait so that perhaps you can take a better one afterwards. But having to save every single image (because it might eventually happen to be better than latter ones) makes you concentrate more on clicking Save and OK than capturing the images. If it was possible to cancel taking a snapshot and to return to the last captured image, you could just take some snapshot and then try to take another one and yet another one but always be able to go back to the previously taken one. This would make work faster and easier. And it only requires binding one key combination to the action of cancelling the snapshot and restoring KSNapshot window. I don't see how I can do this - pretty much any key I might bind is used by some application that get snapshots and I'd have to use something obvious for people to know they could do it. A visual indicator would solve that, but it would screw up the the capture. I just don't see a way to do it I'm afraid. I'll leave the bug open as I agree it is useful, but I can't see how it can be done. If the key used to cancel taking the screenshot was configurable, users could change it as needed to not interfere with their applications. An alternative would be to keep history of configurable length with the possibility to go back a number of screenshots. This would also solve the problem as one would just take the unwanted screenshot but being able to go back one screenshot in the history, the user would still get the change of saving the previous one. > pretty much any key I might bind is used by some application that get > snapshots True, so you could not assign anything. > and I'd have to use something obvious for people to know they could do it. Not at all. 1) User could by her/himself assign proper key, and kdelibs would detect conflict. 2) you could store a list of shortcuts, prntscr, shift+printscrn and assing automatically after first run the first available one 3) open shortcut config dialog on first run and then (1) Anyway, the problem is user cannot control fully KSnapshot, if you by mistake type 33 seconds instead of 3 you cannot get back -- you have to wait. Should we move on over this bug? Because as stated in the announcement of KDE Applications 15.12.0 on page https://www.kde.org/announcements/announce-applications-15.12.0.php, "After 14 years of being a part of KDE, KSnapshot has been retired and replaced with a new screenshot application, Spectacle." This problem is not valid in Spectacle. Quite an old bug indeed. Closing. |