fix: Crash when bounding box touches image edge - #240
Merged
vietanhdev merged 1 commit intoJul 11, 2026
Conversation
intersection_point() returned QPoint (integer coords) while every other coordinate in the shape pipeline uses QPointF. When a user dragged a bounding box to the image edge, the QPoint was stored into self.line.points and eventually hit QPainterPath.lineTo() which expects QPointF, causing a TypeError crash in Shape.paint(). Changed all three return statements in intersection_point() from QPoint to QPointF so the types stay consistent throughout the drawing pipeline.
LeonKraim
changed the title
Owner
|
Thanks for the clean fix, @LeonKraim — merged as 2b093a5. Fixing For anyone following along: there's a third, independent crash in the same area ( |
3 tasks
vietanhdev
added a commit
that referenced
this pull request
Jul 11, 2026
bounded_move_shapes() mixed QPointF (pos, from mouse events) with QPoint literals when clamping a dragged shape to the pixmap border, raising a TypeError when a selected shape is dragged near the image edge. This is the same class of bug as #237/#240 (intersection_point returning QPoint) but an independent instance, since this path never calls intersection_point(). Co-authored-by: chaosbee <chaosbee@163.com>
2 tasks
vietanhdev
added a commit
that referenced
this pull request
Jul 11, 2026
…242) Copilot's review of #241 flagged that the left/top clamp still did int(o1.x()) before wrapping in QPointF, so sub-pixel overflows (e.g. -0.3) truncate to 0 and silently fail to correct the position. Verifying that fix surfaced a second, independent bug in the same lines: the right/bottom clamp corrects against pixmap.width()/height() instead of (width() - 1)/(height() - 1), which is the bound out_off_pixmap() actually enforces — so a shape overflowing the right or bottom edge stayed uncorrected regardless of the int() truncation. Both are pre-existing (predate #237/#238/#240/#241); this PR only touches the four lines already modified by #241. Adds a regression test covering both edges plus the original TypeError crash path.
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
intersection_point() returns \QPoint\ (integer coords) while every other coordinate in the shape pipeline uses \QPointF. When a user drags a bounding box (or polygon, linestrip) to the image edge, the projected edge point (\QPoint) gets stored into shape/line point lists and eventually reaches \QPainterPath.lineTo(), which refuses \QPoint\ — causing a \TypeError: argument 1 has unexpected type 'QPoint'\ crash at \shape.py:199.
Fix
Changed all three return statements in \intersection_point()\ from \QtCore.QPoint\ to \QtCore.QPointF\ so types stay consistent through the entire drawing pipeline.
Related
Fixes a crash that occurs when creating or editing any shape type at the image boundary.