For a wonderful brief period Spectacle gained the crop feature last year.
Alas, just as suddenly (due to a library change) the feature left.
Crop is absolutely essential to a screensaver, the extra workflow to reopen a saved image and crop it in, for example Gwenview, is significant.
Cropping is now a daily task carried out by even unsophisticated users to share images and information.
Cropping is available intuitively when users take screenshots on almost all devices, iPhone, Windows, Gnome, Mac etc…; except those running KDE.
(There are alternatives like Flameshot, but Spectacle is built-in for most users and that’s not a reason to leave it off).
Not that I disagree that it should be re-added, but is there a reason why you can’t eliminate the need for it in the first place by taking a Rectangular Region screenshot of only the area you want to see, rather than a Full Screen screenshot and then cropping it later?
For me, and I imagine many users, I realise that but still find the current behaviour slower and frustrating, it’s about workflow.
Sorry for this long answer:
I might be screenshotting a video, a dynamic website, or a visual glitch (for example illustrating a bug), I’ll want to catch it quick first, then with it safely captured, decide how to crop and annotate it after.
Even if it’s a static screen I’m capturing, it’s fitting the annotation process that I want to play around with which bits to show, to crop, and how best to annotate and present. If I have to choose a rectangular area to start with and make a mistake or change my mind, I have to start all over, whereas with cropping I can play around with the crop and annotation, undo, and visualise before finalising.
If I have to choose the area first before cropping, and annotate it after, this breaks a smooth edit process into 2 more clumsy stages. (I guess this point is an extension of point 2).
The general workflow in other devices and apps is too capture an area first and then crop/annotate it before sharing or saving. Hence I, and I expect others, intuitively press PrtScr first to capture.
You can “screenshoot exactly the area you need” is the engineering answer, I totally get that reasoning: provides the same functionality, cuts down another code path/feature to maintain etc.
But as a end-user I’m also very irritated by the missing crop tool. It’s such a basic functionality that I expect to exist. So I usually don’t care if I just do a rough area or even fullscreen screenshot (if that is the current default). Until I want to crop down the screenshot … oh, you can’t do that.
Esp. on a screenshot I want to annotate - which is so easy now - it is hard to make an estimate how much additional screen space I’m going to need outside of the actual area of interest.
Exactly, but that doesn’t help when you are trying to capture something that is happening live.
I tend to have my Spectacle setup to work with a simple click of the Prt Sc key. I see a quick flash of the screenshot and then it all just closes. When I open the folder and click on the image, it opens with Gwenview and I can crop from there. I would prefer to do it from Spectacle as I am doing the screenshots, but that option is not available to me. Why I should have to open the image in a second program to crop, as it makes no sense. I can annotate, save in multiple formats, etc, but I cannot crop? Who thought this up?
JFYI, some history here: Spectacle never had a crop tool for most of its existence. At some point it gained inline annotations, via the 3rd-party KImageAnnotator library. As a result, when that library gained features, Spectacle got them automatically. And at a certain point this happened and a crop tool was added to it, so Spectacle effectively had cropping functionality, provided accidentally through that library.
Then a few months later, Spectacle was rewritten in QML by @ndavis to be more maintainable for the future and to integrate a KDE screen recording library, which was QML only. But the old annotations library was not QML, it was QtWidgets, which meant it wasn’t compatible, so Noah also had to rewrite the annotations feature. This provided the opportunity to improve the UX by integrating annotating functionality directly into the Rectangular Region selector, instead of having a somewhat clunky child window crammed full of features. This was also a much-requested feature. However as a consequence of that, the new annotation feature, while being better-integrated, didn’t implement all of the functionality of the old 3rd-party library, and we stopped gaining new features for free.
Everything in life is a trade-off, and so it was here as well. Hopefully the crop feature–which seems to be very popular–will eventually be re-implemented.
Well, on contrary to people above, I don’t really see why Spectacle should have annotation and other picture editing functions.
On smartphones, you take a screenshot using some gesture. And there’s nothing to configure. It’s always fullscreen and always png. Then you tap the popup to open the standalone photo editor - the same that you can use for camera and any other pictures. You are supposed to do all editing/cropping/annotation/resizing/saving as jpg/… there, in a familiar, standard app.
In KDE, that would be moving the annotation function into Gwenview, and a button in Spectacle to open it.
That would solve the problem that if I take a screenshot, and later want to add annotation, there seems to be no way. The annotation tool is a one-time offer. And no, the solution definitely shouldn’t be “add a Open button in Spectacle”.
This is a legit question, but IMHO the answer should be: “No, let’s make sure you can’t annotate and can’t save in multiple formats (in Spectacle), to be consistent, and to avoid duplicating functionalities all around KDE.”
Yes. And how about lifting it up to the main toolbar and renaming to “Edit”?
Or how about just open Gwenview directly on screenshot? What do I gain doing the editing in Spectacle instead of in Gwenview?
Yes, but with complete different UI. Why duplicating the function AND making it different in look?
Once you add cropping to Spectacle, it seems more ridiculous to the user that you have annotation and cropping, but not resizing. If you have to reimplement all these image editing in QML, why not do it in a standalone, new QML-based image viewer/editor app?
It’s an interesting idea. There would be some advantages, but also disadvantages:
We can’t count on Gwenview or even any image viewer being installed
Not all image viewers that might be installed have annotations functionality
Hardcoding only Gwenview to work around those issues would effectively make Gwenview a dependency on Spectacle, which obviously isn’t ideal
Delegating annotations to another app slows down the process of annotating images and doesn’t allow for the option of integrating annotation right into the rectangular region mode
Delegating annotations to another app required saving the screenshot to a file somewhere so the other app could access it, which might not be desirable and depending on your settings could clutter your screenshots folder with a bunch of junk images
Workflows involving annotating and then sharing a screenshot would become more awkward and slow, and depend on the sharing functionality of the image editing app
To chime in on this: I absolutely love the annotation tools inside spectacle (before I used flameshot for exactly that reason) and having an “edit” button that opens in an external editor absolutely does not even come close to replacing that, even if the external app has feature parity (or even more features) - there’s a reason I didn’t use Spectacle before it gained annotation features internally.
That said, cropping is something I do sometimes want to do - 99% of my screenshots are “rectangular region” and the (almost) only exception is when I’m trying to screenshot elusive dropdowns, tooltips or other things that close itself when doing a rectangular region screenshot and as such are impossible to screenshot with it. For these I use the print screen button to just screenshot my entire workspace - but then I’m missing cropping functionality.
What I’m currently doing is make a full screenshot, save it, open it in another app (eg: gwenview) and then make a rectangular region screenshot of the area I want (sometimes I crop it “properly” in gwenview, but less often, just because it simply takes longer than another rectangular region screenshot)
On most Android phones (dependant on the flavour) and also with Mac screenshot, the User clicks on the screenshot and can then crop and otherwise annotate it immediately, and then directly share it/save it, without opening a new window & interface (unlike the proposal to use Gwenview which would spawn a different window and interface).
Also as has been pointed out, Gwenview is not a dependency of Spectacle.
Even in contacts list software or websites Cropping is often available smoothly within an interface when uploading images and avatars for example.
Using just Spectacle, for the user, requires no set-up, no thought, no separate app installed. (And there remains the option to user other more advanced software if required.)
I hear the point about not duplicating, and I don’t know how feasible, but ideally an underlying library would be used to provide the same functionality, but embedded in different software views to provide the smoothness and simplicity expected in a efficient modern UI. (Clearly that didn’t work out so well when the previous library had to be abandoned in order to adopt full QML).