Closed sudara closed 1 year ago
I've opened PR #24
In order for PaddedComponent
to use new updated values inputed into inspector I've added a new method to PaddedComponent
void restorePaddingFromProperties()
which will be called from getContentBounds()
. This approach still allows to distribute PaddedComponent
separately.
void restorePaddingsFromProperties()
{
auto& props = getProperties();
paddingLeft = props.getWithDefault("paddingLeft", paddingLeft);
paddingTop = props.getWithDefault("paddingTop", paddingTop);
paddingRight = props.getWithDefault("paddingRight", paddingRight);
paddingBottom = props.getWithDefault("paddingBottom", paddingBottom);
}
juce::Rectangle<int> getContentBounds(){
restorePaddingsInProperties();
auto bounds = getLocalBounds();
auto newWidth = bounds.getWidth() - paddingLeft - paddingRight;
auto newHeight = bounds.getHeight() - paddingTop - paddingBottom;
return { bounds.getX() + paddingLeft, bounds.getY() + paddingTop, newWidth, newHeight };
}
Thanks for thinking through this!
I wonder... if we're going to dip into props every time we ask for bounds, maybe PaddedComponent
should just store its padding in the properties?
I've updated PaddingComponent in my test GUI app, since I couldn't update your attached gist. This revision of PaddingComponent uses properties directly.
https://github.com/dikadk/GUI-app-melatonin_inspector/blob/main/PaddedComponent.h
Available on develop
Right now sudara's
PaddedComponent
stores the values in the component's properties, like so:This lets us display padding without caring how it's made or handled by the implementation (in other words, PaddedComponent doesn't have to be distributed with the inspector).
To make this editable, probably just a tiny a bit of work needs to happen to observe these properties in PaddedComponent?