[Bug]: Crop overlay cursor does not reliably change on border hover #165

New issue

Closed

opened 2026-08-20 04:52:00 +00:00 by Grok · 1 comment

Grok commented

2026-08-20 04:52:00 +00:00

Member

App version

Current main (crop tools from issue #147)

Platform

Linux / Windows

Steps to reproduce

Open Grid viewer on an image.
Enter Crop.
Hover the crop border (corners, edges, and the solid handle marks).
Drag a handle, release, then hover the border again.

Expected behavior

The pointer changes to the matching resize or move cursor whenever it is over an interactive crop handle or inside the selection.

Actual behavior

The cursor often stays the default/open-hand pointer on the border, especially after a drag or on a fitted large image.

Additional context

Likely causes:

Mouse-up after a crop drag restores ScrollHandDrag, which forces OpenHandCursor while crop mode is still active.
Hover MouseMove is not consumed, so QGraphicsView can overwrite the viewport cursor.
Handle hit radii are in image pixels, so fitted large photos have a ~few-pixel grab zone that does not match the visible border.

### App version Current main (crop tools from issue #147) ### Platform Linux / Windows ### Steps to reproduce 1. Open Grid viewer on an image. 2. Enter Crop. 3. Hover the crop border (corners, edges, and the solid handle marks). 4. Drag a handle, release, then hover the border again. ### Expected behavior The pointer changes to the matching resize or move cursor whenever it is over an interactive crop handle or inside the selection. ### Actual behavior The cursor often stays the default/open-hand pointer on the border, especially after a drag or on a fitted large image. ### Additional context Likely causes: - Mouse-up after a crop drag restores `ScrollHandDrag`, which forces `OpenHandCursor` while crop mode is still active. - Hover `MouseMove` is not consumed, so QGraphicsView can overwrite the viewport cursor. - Handle hit radii are in image pixels, so fitted large photos have a ~few-pixel grab zone that does not match the visible border.

Grok added the

Kind/Bug

Priority/Medium

Reviewed/Confirmed

labels

2026-08-20 04:52:15 +00:00

Grok commented

2026-08-20 04:56:51 +00:00

Author

Member

Fixed on 0.6.0/issue-165-crop-cursor (5d8a2a5).

Cause: three things stacked so the pointer often stayed arrow/open-hand on the crop border:

Mouse-up after a handle drag restored ScrollHandDrag, which forces OpenHandCursor while crop mode was still active.
Hover mouse-move was not consumed, so QGraphicsView could overwrite the viewport cursor.
Handle hit radii were in image pixels, so a fitted large photo had only a few screen pixels of grab zone (and a dead zone between the corner circle and inset edge segments).

Fix: keep NoDrag for the whole crop session; consume hover/move and set the cursor from hit-testing; convert corner/edge radii to viewport pixels; drop the edge inset; cosmetic border pens; overlay graphics ignore mouse so they do not steal hover.

No PR to main until requested.

Fixed on `0.6.0/issue-165-crop-cursor` (`5d8a2a5`). **Cause:** three things stacked so the pointer often stayed arrow/open-hand on the crop border: 1. Mouse-up after a handle drag restored `ScrollHandDrag`, which forces `OpenHandCursor` while crop mode was still active. 2. Hover mouse-move was not consumed, so QGraphicsView could overwrite the viewport cursor. 3. Handle hit radii were in image pixels, so a fitted large photo had only a few screen pixels of grab zone (and a dead zone between the corner circle and inset edge segments). **Fix:** keep `NoDrag` for the whole crop session; consume hover/move and set the cursor from hit-testing; convert corner/edge radii to viewport pixels; drop the edge inset; cosmetic border pens; overlay graphics ignore mouse so they do not steal hover. No PR to `main` until requested.

Grok closed this issue

2026-08-20 04:56:53 +00:00

Grok referenced this issue from a pull request that will close it,

2026-08-20 21:45:00 +00:00

Fix crop overlay handle cursors on hover (0.6.1, issue #165) #169