You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of having different "modes" for the screenshot tool, where it can snap a window or the full screen, perhaps the screenshot tool should just do both when invoked. That way, one isn't forced to choose ahead of time, and to remember two separate keybindings; instead, one just "takes a screenshot" with PrtSc or similar and then can be presented with both a fullscreen and a window screenshot. (Obviously, the UI might decide to present these separately rather than simultaneously -- one is shown a fullscreen screenshot and then choosing "Window" switches that to show the already-taken window screenshot -- if that's deemed a better approach.)
This can also be extended to other classes of screenshots; for example, if switching CSS fonts for an app can be done very quickly, then the screenshot tool might take a fullscreen, a windowed, and a windowed-with-the-REDACTED-font screenshot, and allow choosing between them. This has the advantage that it exposes the existence of the redaction scheme to people who might not otherwise have thought to do it. (Clearly it won't work if taking a redacted screenshot takes a great deal of time or is visually disruptive, since people won't want to pay that time cost for every screenshot if they didn't want that.)
Launchpad Details: #LP1556474 Stuart Langridge - 2016-03-12 18:29:33 +0000
What about the option to take a screenshot of selected rectangle? Sure, could be done with UX similar to shotwell image cropping, but it might be an overkill. To me, the current design is adequate (talking from 2022).
Instead of having different "modes" for the screenshot tool, where it can snap a window or the full screen, perhaps the screenshot tool should just do both when invoked. That way, one isn't forced to choose ahead of time, and to remember two separate keybindings; instead, one just "takes a screenshot" with PrtSc or similar and then can be presented with both a fullscreen and a window screenshot. (Obviously, the UI might decide to present these separately rather than simultaneously -- one is shown a fullscreen screenshot and then choosing "Window" switches that to show the already-taken window screenshot -- if that's deemed a better approach.)
This can also be extended to other classes of screenshots; for example, if switching CSS fonts for an app can be done very quickly, then the screenshot tool might take a fullscreen, a windowed, and a windowed-with-the-REDACTED-font screenshot, and allow choosing between them. This has the advantage that it exposes the existence of the redaction scheme to people who might not otherwise have thought to do it. (Clearly it won't work if taking a redacted screenshot takes a great deal of time or is visually disruptive, since people won't want to pay that time cost for every screenshot if they didn't want that.)
Launchpad Details: #LP1556474 Stuart Langridge - 2016-03-12 18:29:33 +0000
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: