Skip to content
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

Correct scaling of MIN_WIDTH and MIN_HEIGHT on Android and WinForms #2186

Merged
merged 2 commits into from
Nov 2, 2023

Conversation

mhsmith
Copy link
Member

@mhsmith mhsmith commented Nov 2, 2023

The minimum sizes were being converted to CSS pixels even though that's what they already were. This caused them to be too small.

Also took the opportunity to reduce duplicated code by assigning default intrinsic.width and intrinsic.height values in the base class.

@mhsmith mhsmith marked this pull request as ready for review November 2, 2023 20:55
Copy link
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've got a bunch of questions about this, mostly related to consistency and enforcing minimum sizes (usually width). Comments are inline; however, I'm going to merge on the basis that it definitely corrects some of the issues I've been seeing with widget sizing.

The issues I've raised can all be safely fixed in a follow up PR, if necessary.

intrinsic.width = intrinsic.height = None
# Default values; may be overwritten by rehint().
self.interface.intrinsic.width = at_least(self.interface._MIN_WIDTH)
self.interface.intrinsic.height = at_least(self.interface._MIN_HEIGHT)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these default values be scaled out?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because they're already in CSS pixels. The intention of this PR is that when sizes are assigned to intrinsic.width or intrinsic.height, they are already in CSS pixels as the interface layer expects, so they don't need to be scaled again.

@@ -42,4 +43,6 @@ def create(self):
def rehint(self):
self.interface.intrinsic.width = at_least(300)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this constant value be scaled (and/or expressed in terms that are suitable for scaling?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, for the same reason as above. And since date and time pickers look quite different on each platform, I think it makes sense for the backend to have its own value in this case, rather than defining a _MIN_WIDTH that they all share.

self.interface.intrinsic.width = at_least(self.native.getMeasuredWidth())
self.interface.intrinsic.height = self.native.getMeasuredHeight()
self.interface.intrinsic.width = self.scale_out(
at_least(self.native.getMeasuredWidth()), ROUND_UP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this have a MIN_WIDTH component to ensure it doesn't just collapse to the smallest possible rendered size?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that would probably be better, and more consistent with some of the other backends. I didn't do that in this PR because I wanted to limit it to just one problem at a time.

android/src/toga_android/widgets/selection.py Show resolved Hide resolved
android/src/toga_android/widgets/slider.py Show resolved Hide resolved
winforms/src/toga_winforms/widgets/slider.py Show resolved Hide resolved
@freakboy3742 freakboy3742 merged commit d661272 into beeware:main Nov 2, 2023
35 checks passed
@mhsmith
Copy link
Member Author

mhsmith commented Nov 6, 2023

Continued in #2200.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants