-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buttons with no content don't lay out correctly #1513
Comments
I got some help from @marlitas on this, and we discovered that the preferred height and width are zero for these buttons. Here's a screen shot: We also found that adding any content to the buttons makes them lay out correctly, though they seem to size themselves a little oddly. Here is a screenshot of a case where I added the option This led @marlitas and I to conclude that this is a general problem with |
I ran into a buttonConstraint layout issue in Number Line Integers as well. I don't think they're exactly related, but seem to be in the same area. In this case The below patch fixes the bug I encountered, but also feels like it might be potentially mis-using Would like to discuss with @jonathanolson Subject: [PATCH] Center text dynamically, see: https://github.com/phetsims/number-line-integers/issues/108
---
Index: js/buttons/RoundButton.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/buttons/RoundButton.ts b/js/buttons/RoundButton.ts
--- a/js/buttons/RoundButton.ts (revision 26851caba268b49f4abbd8a50e4ce4372cc625b6)
+++ b/js/buttons/RoundButton.ts (date 1699573275871)
@@ -78,14 +78,6 @@
assert && assert( typeof options.radius === 'number', `invalid radius: ${options.radius}` );
}
- if ( options.radius ) {
- assert && assert( options.xMargin < options.radius, 'xMargin cannot be larger than radius' );
- assert && assert( options.yMargin < options.radius, 'yMargin cannot be larger than radius' );
-
- options.minUnstrokedWidth = options.radius * 2;
- options.minUnstrokedHeight = options.radius * 2;
- }
-
// If no options were explicitly passed in for the button appearance strategy, pass through the general appearance
// options.
if ( !options.buttonAppearanceStrategyOptions ) {
@@ -99,6 +91,18 @@
const buttonRadius = options.radius ||
Math.max( options.content!.width + options.xMargin * 2, options.content!.height + options.yMargin * 2 ) / 2;
+ if ( options.radius ) {
+ assert && assert( options.xMargin < options.radius, 'xMargin cannot be larger than radius' );
+ assert && assert( options.yMargin < options.radius, 'yMargin cannot be larger than radius' );
+
+ options.minUnstrokedWidth = options.radius * 2;
+ options.minUnstrokedHeight = options.radius * 2;
+ }
+ else {
+ options.minUnstrokedWidth = buttonRadius * 2;
+ options.minUnstrokedHeight = buttonRadius * 2;
+ }
+
if ( options.content && options.radius ) {
const previousContent = options.content;
const minScale = Math.min( |
…nforce square minimum bounding rectangle, see phetsims/scenery#1513
Tracking progress in button-layout branch |
@jbphet I believe this is resolved. Do you mind checking briefly? |
Sun demo (where the problem was initially noticed) is lookin' good: Also, the values shown by the Scenery helper seem more reasonable: I also checked the case where text content is added to the buttons as a sort of a regression test, and it looked fine. @jonathanolson - Hopefully this is what you meant by "checking briefly". Let me know if you need any additional review. I haven't review the code, just the behavior. |
Yup, thanks! Closing. |
Saw this in the sun demo just now while testing changes for phetsims/sun#292.
The text was updated successfully, but these errors were encountered: