The current behavior is that dragging anywhere on the image while the cropping tool is active starts dragging on the closest corner of the cropping area, or, when the user is holding Shift Ctrl, they can paint a new rectangle (i.e. one corner is where they start dragging, the other is where they stop).

I feel like that behaviour could be polished – feel free to suggest changes @jtheoof.

Edit: Changed Shift to Ctrl.

Changed the behavior slightly so that the initial rectangle is drawn as-if Ctrl was being held. Subsequent drags resize the existing crop rectangle.

This felt more natural to me and is indicated by the cursor.

I'm also thinking maybe the rectangle could actually be split into thirds, like so:

+----+----+----+
| TL | T  | TR |
+----+----+----+
| L  | CC | R  |
+----+----+----+
| BL | B  | BR |
+----+----+----+

and drag actions would be: TL resizes by top-left corner, T resizes by top edge, TR resizes by top-right corner, L resizes by left edge, etc.; CC would simply move the rectangle without resizing.

Hi and thank you for your contribution! I like the way you implemented it! I guess implementing this feature will finally get swappy one of the preferred tool to use in combination with grim.

I'm also thinking maybe the rectangle could actually be split into thirds, like so:

Personally I would prefer a smaller size of thirds, current are big enough for this task.

Also I would like to suggest to start painting a new rectangle if the user start to draw it outside of the current one - this was expected behaviour for me, but I got resizing current.

Thanks for the input, @itsTurnip!

Personally I would prefer a smaller size of thirds, current are big enough for this task.

Do you mean the current state is fine by you or are you proposing to make them even smaller? Currently, they are not thirds, they are actually quarters (as I, too, thought thirds were too big).

Also I would like to suggest to start painting a new rectangle if the user start to draw it outside of the current one - this was expected behaviour for me, but I got resizing current.

Sounds like a good idea. The current behaviour is that when you hold Ctrl, you draw a new rectangle, but perhaps making the whole control mouse-only could be better. I'll try what it feels like to me.

are you proposing to make them even smaller? Currently, they are not thirds, they are actually quarters (as I, too, thought thirds were too big).

Yup, that was what I tried to say.

Actually, I think it should be a fixed size (just for e.g., 15px). It's not really necessary for this zones to be adjustable after the size of the rectangle. Like for a window managers: a zone to start a windows resize usually have a fixed size.

Actually, I think it should be a fixed size (just for e.g., 15px). It's not really necessary for this zones to be adjustable after the size of the rectangle. Like for a window managers: a zone to start a windows resize usually have a fixed size.

Makes sense, yeah, just as I was playing around with it some now, I also thought maybe I should make the zone fixed-size. One thing to consider is that windows generally have more controls inside of them, as opposed to this crop rectangle, so perhaps the case could be made for the zones to be bigger. But yeah, having the zone size be a fraction is probably not the best UX – not that I personally actually notice in day-to-day use, but it is something to think about.

Anyway, in the meantime I changed the behaviour to be so that when dragging outside of the rectangle, you draw a whole new one. I agree that this is probably more intuitive, I like it.

(I left the Ctrl option in for now as well... probably does not hurt to have it and it's not in any way a considerable amount of extra code to maintain)

Anyway, in the meantime I changed the behaviour to be so that when dragging outside of the rectangle, you draw a whole new one. I agree that this is probably more intuitive, I like it.

I tested it. Liked this too 👍

Another thing that I would suggest is to change border dragging. Here's how it works right now:

You see this: when I try to change the size of the current rectangle it resizes to my cursor position. But I would like to start moving the current position of the border, not to start a new one.

There's also a visual bug I found. When you start moving the border inside the rectangle the cursor changes it's appearance from cross-hair to the angle. It looks fun when you try to lower the width and higher the height: it starts to blink 😄

Right, relative movement is probably better. Done it now.

The cursor flicker is fixed now as well.

Thanks for your inputs so far!

Note: I've put TODOs about what I want to definitely have done before I consider this PR finished. It may not be exhaustive – feel free to suggest more fixes/improvements.

Alright, I just pushed the change that makes it so that the rectangle does not change its size when it's being dragged against the edges. From where I stand, this crosses off the last TODO I set for myself, so I think the PR is ready.

Actually, scratch that, there are two more things that probably need doing before this is final:

• Make the crop tool work with the Undo action
• Add the ability to reset the crop

Thank you for this @Spiffyk I'm gonna try to review this soon

Hey, awesome extension on the tool !! I think a way to specify that the tool always start in crop mode in the config file would be super helpful too. Really nice implementation there !!

@Niranjan-GopaL: I think a way to specify that the tool always start in crop mode in the config file would be super helpful too.

That's already supported, see paint_mode in the README 🙂

Thank you for this @Spiffyk really nice effort was put here. I finally had time to look into it. After testing it, my first feedback is that perhaps we should consider a simplified approach. Not allowing the user to "edit" the crop as you did here, which looks a bit odd as the cursor seems to move away the more I edit the crop (see below)

What I suggest instead is to apply the crop on mouse button release (and updating the paint buffer completely) but plugging it with the undo system, so it's easy to go back to previous state and do a new crop if we messed up.

I've update the CI, it's been a while and github actions were not up to date. Can you please rebase when you get a chance? Some code did not pass the run-clang-tidy -p build when I check this MR. The CI will complain after rebase if not fixed.

Hi, sorry about the delay, @jtheoof!

I just rebased the branch, added a missing dependency declaration (build on NixOS would fail without it), and reformatted.

After testing it, my first feedback is that perhaps we should consider a simplified approach. Not allowing the user to "edit" the crop as you did here, which looks a bit odd as the cursor seems to move away the more I edit the crop (see below)

What I suggest instead is to apply the crop on mouse button release (and updating the paint buffer completely) but plugging it with the undo system, so it's easy to go back to previous state and do a new crop if we messed up.

Right, that sounds like a very reasonable approach to me! I'll go ahead and look into adapting the behaviour.

So I've reworked the tool quite a bit, merging it into the other paint types (as it should have been all along). This way, it integrates with the existing undo-redo mechanism. The editing logic is now gone.

Right, I changed the keybind from c to z because #183 was merged and conflicted with this. Feel free to suggest a different keybind as I'm not sure what would be fitting mnenonically.

I cleaned up a bit and squashed the history, removing the gio-unix change (now in #217).

For now, it's two commits, with the state before and after the rework, but I plan on squashing it up into a single commit once we reach definite agreement on how it's supposed to work.