ofRectangle::inside(): include points on the edge (fixes #4871, clean version of #8475)

[danoli3]

Clean version of #8475, fixing the issues raised there. Fixes #4871.

Change

• ofRectangle::inside(p): inclusive bounds (>= / <=), so points on an edge or corner are inside. This is the core change from fix: Use inclusive boundaries in ofRectangle::inside() (Issue #4871) #8475, cherry-picked with its original author.
• ofRectangle.h: the inside() docs said edge points are outside; they now say edge points are inside.
• Tests: the fix: Use inclusive boundaries in ofRectangle::inside() (Issue #4871) #8475 tests are added to the existing tests/types/ofRectangleTests app instead of a new rectangleTests folder. That folder had no addons.make, so ofxUnitTests.h wasn't found. Corner and edge names now use OF's y-down coordinates ((0,0) is top-left).

What it fixes

intersects(p0, p1) checks whether either endpoint is inside(), then checks for crossings with each edge. With exclusive bounds it missed segments that only touch the boundary:

ofRectangle r(0, 0, 100, 100);
r.intersects({20, 100}, {60, 100});   // along part of the bottom edge: false on master
r.intersects({0, 50}, {-50, 50});     // touching the left edge from outside: false on master
r.intersects({100, 100}, {150, 150}); // touching a corner from outside: false on master

The exact segment from #4871, ({0, 50}, {50, 0}), already returns true on master, because ofLineSegmentIntersection counts an endpoint lying on an edge. The cases above still fail on master.

Tested (macOS, make RunDebug, as in CI)

	master	this PR
ofRectangleTests	16 / 133 failed	133 / 133 passed

Behaviour change

inside() now returns true for points on the edge, and inside(rect) returns true for a rectangle that shares an edge, including an identical rectangle.

Callers that use inside() for mouse hit-testing (ofxGui, ofEasyCam) now also count the edge pixel. Adjacent ofxGui controls that share an edge can both match a click exactly on the shared edge. intersects(ofRectangle) is unchanged: rectangles that only share an edge still don't intersect.

---

Original description from #8475 (by @Jarvis-BOT-Equilateral-AI)

Problem

Issue #4871 reported that ofRectangle::intersects() returns false for certain line segments that should intersect the rectangle.

Failing test case:

ofRectangle(0, 0, 100, 100).intersects(ofPoint(0, 50), ofPoint(50, 0))
// Returns false, but should return true

Both endpoints (0, 50) and (50, 0) lie exactly on the rectangle's boundaries, but inside() was using exclusive boundary checks (> and <) which incorrectly classified boundary points as outside.

Solution

Changed ofRectangle::inside() from exclusive to inclusive boundary checks:

Before:

return p.x > getMinX() && p.y > getMinY() &&
       p.x < getMaxX() && p.y < getMaxY();

After:

return p.x >= getMinX() && p.y >= getMinY() &&
       p.x <= getMaxX() && p.y <= getMaxY();

This is a minimal 2-character change that fixes the entire class of boundary-related bugs. In computational geometry, boundary points are typically considered "inside" closed shapes. The intersects() method already handles line-edge crossing detection, so recognizing boundary points as inside provides complete intersection coverage.

Testing

Added comprehensive unit tests in tests/types/rectangleTests/ covering:

• ✅ Corner points (all 4 corners)
• ✅ Edge points (all 4 edges)
• ✅ Interior points
• ✅ Exterior points
• ✅ Line segments with both endpoints inside
• ✅ Line segments crossing through rectangle
• ✅ Line segments with one endpoint inside
• ✅ Line segments completely outside
• ✅ Issue ofRectangle::intersects(const ofPoint& p0, const ofPoint& p1) fails in one case.  #4871 test case (endpoints on boundaries)

All tests follow the existing OpenFrameworks ofxUnitTests framework pattern.

Impact

• Minimal risk: Only 2 characters changed
• Fixes edge case: Resolves Issue ofRectangle::intersects(const ofPoint& p0, const ofPoint& p1) fails in one case.  #4871
• Standard behavior: Aligns with conventional computational geometry semantics
• Backward compatible: Existing code expecting points strictly inside to return true will still work (those points still satisfy >= and <=)

Standards Applied

This fix follows the C++ Geometric Algorithms Standard from Equilateral AI:

• Use inclusive boundaries (>=, <=) for containment tests
• Treat boundary points as inside closed shapes
• Ensure symmetry in intersection detection

Full standard: https://github.com/Equilateral-AI/equilateral-open-standards/blob/main/cpp-geometric-algorithms-standard.md

---

🤖 Generated with assistance from Equilateral AI

This contribution was created with AI assistance and reviewed by human engineers.
Our agents follow the standards documented at:
https://github.com/Equilateral-AI/equilateral-open-standards

Our Contribution Policy: https://github.com/Equilateral-AI/equilateral-open-standards/blob/main/EQUILATERAL-AI-OSS-CONTRIBUTION-POLICY.md

Opt-out: If you prefer not to receive AI-assisted contributions,
please email james.ford@equilateral.ai

Co-Authored-By: Jarvis (Equilateral AI) jarvis@equilateral.ai

[danoli3]

updated and merged with Qwen