Bug 495036

Summary: [UX Problem] Applying crop and then saving doesn't apply crop
Product: [Applications] Spectacle Reporter: Ellie <el>
Component: GeneralAssignee: Noah Davis <noahadvs>
Status: RESOLVED INTENTIONAL    
Severity: normal CC: kde
Priority: NOR    
Version First Reported In: 24.08.1   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Screenshot showing GIMP's floating text tool buttons that provide extra options and which are hard to miss

Description Ellie 2024-10-19 12:07:31 UTC
SUMMARY

I assume the UI perhaps expects me to do this differently, but I think then the UI of Spectacle should perhaps be laid out differently: but when I click "Edit" and crop an image and then save, the image isn't cropped.

STEPS TO REPRODUCE

1. Press print key to get screenshot in spectacle
2. Click "Edit"
3. Click the rectangular crop tool button in the vertical side bar to the left
4. Click and drag inside the image to select a crop rectangle
5. Click "Save as" in the horizontal top toolbar
6. Save image in some folder
7. Open image with an image viewer and check if it is cropped

OBSERVED RESULT

Saved image isn't actually cropped.

EXPECTED RESULT

Either the saved image is cropped, or the UI makes it more clear how this workflow is supposed to be used instead.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Ellie 2024-10-19 12:11:02 UTC
It seems like there is a text showing up now that tells me to double-click. This text only showed up after I did that, which doesn't seem like a useful point in time, although sorry if I somehow did something to mess that up that I shouldn't have.

I think instead of using double click here, it would be more intuitive to show a pop-up that hovers near the crop rectangle after it was placed that allows to accept or cancel. Kind of similar to how when you click the text tool in GIMP and select an area to later type in, a formatting options popup will open and hover next to the text area rectangle inside the canvas. I'm hoping this suggestion is constructive and helpful for helping future users figuring out this functionality better.
Comment 2 Noah Davis 2024-10-25 11:45:20 UTC
(In reply to Ellie from comment #1)
> It seems like there is a text showing up now that tells me to double-click.
> This text only showed up after I did that, which doesn't seem like a useful
> point in time, although sorry if I somehow did something to mess that up
> that I shouldn't have.

The text shows up the moment you click on the crop tool in the left side panel, before you start making a selection. After the selection is made, it stays out of the way so you can see what you're doing. Is this not how it works for you?

> I think instead of using double click here, it would be more intuitive to
> show a pop-up that hovers near the crop rectangle after it was placed that
> allows to accept or cancel. Kind of similar to how when you click the text
> tool in GIMP and select an area to later type in, a formatting options popup
> will open and hover next to the text area rectangle inside the canvas. I'm
> hoping this suggestion is constructive and helpful for helping future users
> figuring out this functionality better.

I don't know of any image editors with crop tools that work like that, including GIMP. Most of them work like Spectacle. The current behavior is based on the fullscreen rectangle selection UI, so there is also some internal consistency.
Comment 3 Ellie 2024-10-25 12:07:30 UTC
I'm using GIMP a lot, and I've never had to double-click to apply crop. I tried it just now, and double-clicking in GIMP on a selection doesn't do anything, let alone crop.

Therefore, I'm suggesting floating buttons like GIMP has for the text tool that are harder to miss and seem to be a more common UI for such actions.

> The text shows up the moment you click on the crop tool in the left side panel

I didn't notice it, I can't tell you if it was there or I simply missed it. It's also not obvious how a double-click would work on a touch device.

My apologies if double-click is actually common for this action, but unlike floating buttons, I've never seen any editing tool use this approach.
Comment 4 Ellie 2024-10-25 12:12:29 UTC
Created attachment 175225 [details]
Screenshot showing GIMP's floating text tool buttons that provide extra options and which are hard to miss
Comment 5 Ellie 2024-10-25 12:38:56 UTC
(I forgot to add: if you still think this isn't a useful suggestion, feel free to close this issue!)
Comment 6 Noah Davis 2024-10-25 12:40:17 UTC
(In reply to Ellie from comment #3)
> I'm using GIMP a lot, and I've never had to double-click to apply crop. I
> tried it just now, and double-clicking in GIMP on a selection doesn't do
> anything, let alone crop.
> 
> Therefore, I'm suggesting floating buttons like GIMP has for the text tool
> that are harder to miss and seem to be a more common UI for such actions.

My GIMP (2.10.38) does not have your floating buttons and double clicking a crop region in GIMP does a crop. Krita's crop tool works the same way. Gwenview also behaves the same way. It has been a very, very, very long time since I used Photoshop, but I think it may have also had similar behavior.

> It's also not obvious how a double-click would work on a touch device.

Perhaps touch screen usage is where the difference in our experience comes from? Spectacle is admittedly not really designed for touch right now. It's usable, but it basically just interprets touch input like mouse input without any touch specific UI elements or behavior. I also don't have a good way to test touch input right now.
Comment 7 Noah Davis 2024-10-25 12:40:47 UTC
(In reply to Ellie from comment #5)
> (I forgot to add: if you still think this isn't a useful suggestion, feel
> free to close this issue!)

I'll leave it open for a while.
Comment 8 Noah Davis 2025-07-31 06:14:14 UTC
closing this since the original reported behavior is intentional, but we should still consider improving touch friendliness.