API consistency for juce::Point<int>

Feature Requests
1

Hi there!

Mini DX feature request here. I’ve been working with images and paths daily and usage of juce::Point<int> in particular feels inconsistent / spotty. It’s hard to remember which methods are unhappy taking a point.

There have been requests over the years for things like rect.translated(point) but it hasn’t made it in. For that example, one can do rect + point, but I always forget it exists and it’s less explicit.

Here are some API methods where x,y is or x,y,w,h is still needed:

rect.translated (point.getX(), point.getY()) // inconsistent with AffineTransform
g.drawImageAt (image, point.getX(), point.getY()) 
path.scaleToFit (bounds.getX(), bounds.getY(), bounds.getWidth(), bounds.getHeight(), true); // could accept juce::Rect
path.addArc (x, y, width, height` // could accept juce::Rect

There’s probably a couple others.

Related: Internal and app code could be further cleaned up by introducing juce::Point’s sibling, juce::Dimensions

juce::Image (juce::Image::ARGB, bounds.getWidth(), bounds.getHeight())

becomes

juce::Image (juce::Image::ARGB, bounds.dimensions())
2

Yes! But I would go for juce::Size instead of juce::Dimensions. It is shorter and more consistent with existing methods, such as juce::Rectangle::setSize().

The addition of such a class is briefly discussed here, by the way:

2 Likes
3

Chatting with the team yesterday we agree adding a Size class is sensible and worth while, we’ll try and fit it in soon.

6 Likes