background_color Transparency Fixes

[proneon267]

Fixes #767, Fixes #2425, Fixes #2430

With reference to the issues identified in #2478, I have implemented the related fixes separately in this PR. Reposting from #2478 for reference:
The reason for why only the divider widget triggered the transparency bug on Android and not the existing widgets is that the divider widget is explicitly setting a background color on initialization:

toga/android/src/toga_android/widgets/divider.py

Lines 13 to 14 in 1b96ca1

	# Background color needs to be set or else divider will not be visible.
	self.native.setBackgroundColor(Color.LTGRAY)

Hence, its default background is also not transparent whereas for other widgets, the default background was TRANSPARENT.
I have also fixed a bug on winforms progressbar, which was encountered when I enabled test_background_color_transparent in test_progressbar.

On the backends, there are 3 different possible values for set_background_color()/set_background_color_simple() - None, TRANSPARENT, color(Actual color). I want to propose the following interpretation for them(for the internal backend calls):

• None - Default background color
• TRANSPARENT - Actual transparency and default background color as fallback on widgets not supporting transparency.
• Color - Actual color

Also, as per: https://developer.mozilla.org/en-US/docs/Web/CSS/background-color#formal_definition, the initial value for background_color is transparent, so I also propose to make TRANSPARENT the initial value for background_color.

Let me know what you think and whether I have left out any widgets where the transparency test should be enabled.

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[proneon267]

Regarding the new test, I have added the missing canvas image data test, but since the internal method to patch for testing are platform specific, hence the test is on the probe (Also, on android, canvas._impl.native.getBackground() method cannot be directly monkey patched).
I know this might be a red flag but the other way for the test to be on testbed was to use:

if toga.platform.current_platform is "android":

which you had previously told me to avoid. But, I think that using if toga.platform.current_platform is "android": and keeping the test on the testbed would be more suitable here.

[freakboy3742]

Your proposed interpretation of background color matches what I would expect.

Your proposal to change the default background color also largely makes sense; it's been proposed as a fix for at least 2 issues; see #767 and #2425. However, it will likely have a widespread impact, so we need to be very careful making this change.

As noted inline, the mock-based approach is a non starter; I suspect once that has been removed, the issue about the new test becomes a non-issue.

[freakboy3742]

This isn't an acceptable approach. Mocking is a last resort for testing. It's used in a handful of places related to permissions and hardware APIs because using those APIs requires passing control to a separate process, at which point the test suite loses the ability to execute. Background color is an entirely internal mechanism, and isn't encumbered by this restriction.

It may be difficult to interrogate - but that doesn't mean we can mock it, because we're trying to verify the actual behavior.

[proneon267]

During the test, coverage reported missing coverage for:

toga/android/src/toga_android/widgets/canvas.py

Lines 244 to 247 in dad68bb

	background = self.native.getBackground()
	if background:
	background.draw(canvas)
	self.native.draw(canvas)

I/python.stdout: Name                                                                                                        Stmts   Miss Branch BrPart  Cover   Missing
I/python.stdout: -------------------------------------------------------------------------------------------------------------------------------------------------------
I/python.stdout: data/data/org.beeware.toga.testbed/files/chaquopy/AssetFinder/requirements/toga_android/widgets/canvas.py     153      0     28      1  99.4%   245->247
I/python.stdout: -------------------------------------------------------------------------------------------------------------------------------------------------------
I/python.stdout: TOTAL                                                                                                        2190      0    324      1  99.9%

So, 245->247 means it is reporting missing coverage for the missing else branch. The else branch will be triggered when self.native.getBackground() returns None. Since, it is an internal platform method, I cannot make it return None without mocking it. The other way was to ignore the missing else branch with #pragma: no branch, which you have told me to avoid. So, is there any other way to test the missing else branch or am I missing something?

[proneon267]

NVM, I just realized there was a much simpler way to test this. Thanks :) So, the question remains, should I move the test to testbed or keep it in the probe, since it is implementation specific?

[freakboy3742]

There might be a specific edge case that is needed to exercise that test, but if the other backends don't have an equivalent "if background" branch, then they will run the code without branching, giving double coverage of one specific code path. That's not a problem - it's OK to test something more than once on iOS (et al) if it means we get 100% coverage on Android as well; if nothing else, it's an indication that there are two different test configurations, and we need to test both, even if the "default" implementation works for both cases on iOS.

However, I'm confused because that line did have coverage prior to this change, and it has coverage on every other platform. This, to me, indicates that there's a bigger problem here. Either this branch of code was covering over an edge case that no longer exists, or there's a case that isn't being tested.

[freakboy3742]

What is this test for? We already have a background color test - why do we need to test a normal background color in the transparent background color test?

[proneon267]

I think, this is a debugging artifact, that I had put on for visual inspection of widgets with transparent as default background color. I'll remove it. Thanks.

[proneon267]

While implementing this PR, I discovered a bug in the WinForms Divider widget.

I have corrected the WinForms Divider implementation to use a WinForms.Panel instead of a WinForms.Label, as WinForms.Panel is more suitable for a Divider widget and allows setting a background color.

The previous implementation did not produce any visual results when background color was set. This is because it was producing the Divider widget by squeezing the borders of the WinForms.Label and setting its height to 2 px, which hid its background, resulting in just the borders being visible.

The reason why it was passing tests was because it was setting the background color of the WinForms.Label. However, the probe only checks through the native APIs, which returned the set background color. Since its background was hidden, there were no visual results.

[proneon267]

Also, discovered another bug in Label widget transparent background_color on WinForms.
WinForms.Label although allows setting BackColor to Color.Transparent(doesn't raise transparent background exception), but it doesn't actually work, the background color will be white when set to Color.Transparent. Also tried:

label1.Parent = pictureBox1
label1.BackColor = Color.Transparent

But it only works if the label is inside/above a PictureBox and not for other cases. So, the best bet for transparency is to make label background color same as the container inside which the widget is present. The other way would be to mark Label as _background_supports_alpha = False. I have currently implemented the former method. Which do you think should we choose?

[freakboy3742]

Also, discovered another bug in Label widget transparent background_color on WinForms. WinForms.Label although allows setting BackColor to Color.Transparent(doesn't raise transparent background exception), but it doesn't actually work, the background color will be white when set to Color.Transparent.

Unless I'm misunderstanding, this is what #2425 is describing.

Also tried:

label1.Parent = pictureBox1
label1.BackColor = Color.Transparent

But it only works if the label is inside/above a PictureBox and not for other cases.

If winforms.PictureBox allows transparency but winforms.Panel doesn't, and there's no notable performance hit from using a winforms.PictureBox with no picture in it, this might be a viable option. It also sounds like it might provide a path to putting a background image on toga.Box, which is a request we get occasionally.

So, the best bet for transparency is to make label background color same as the container inside which the widget is present. The other way would be to mark Label as _background_supports_alpha = False. I have currently implemented the former method. Which do you think should we choose?

Is it setting the background to white, or "default background"? We need to be very careful that we're differentiating between those two cases, especially given that background has been getting closer and closer to white over time.

I think the solution may be actually halfway between the two answers you've suggested. My read of #767 and #2425 is that the current _background_supports_alpha=False implementation is problematic. It's currently using the default background color as a fallback, but it should be using the color of the parent container as a fallback, on the basis that if a (for example) button is in a box, it's the box's background color that should be used.

In the case of widgets like Button, we also need to be careful about the use of background - are we describing the button background color, or are we describing the color of the padding around the button.

[proneon267]

Apologies for the delayed response. So, I researched more and did more tests, and found that WinForms doesn't actually support true transparency. The important bit for setting up transparency is:

self.native.Parent = self.interface.parent._impl.native
self.native.BackColor = Color.Transparent

WinForms actually just copies the BackColor of the widget's parent to the widget. Which means, every time the widget's parent changes, we need to reapply background color to copy the new parent's BackColor to the widget. However, if we use the above code, then the behavior becomes highly inconsistent, and even glitches out when the parent is changed. Most of the time transparency works like a fluke. I also tried to use a PictureBox to achieve transparency, but the behavior was same as that of a Panel.

I have found that manually setting a widget's BackColor same as that of the parent widget works most stably, and that is what I have opted to implement. With it, I have fixed #2425(the bug were non transparent Label and Box widgets).

Another bug I have noticed is that when a button's background_color is manually set to another color, like in the above image, then a white border appears. Maybe it is not clearly visible in a white background, but if we change the background to a contrasting color, then it becomes apparent.

The only way to remove it seems to be to change the button's FlatStyle to Flat:

Button.FlatStyle = FlatStyle.Flat
Button.FlatAppearance.BorderSize = 0

But then, it doesn't look like a native button anymore.

As for the new failing canvas tests:

tests/widgets/test_canvas.py::test_background_color_transparent
tests/widgets/test_canvas.py::test_transparency

They are somehow connected to the new set_background_color() method of Box widget, as when I disable the set_background_color() method of Box widget, the error disappears.

[freakboy3742]

I have found that manually setting a widget's BackColor same as that of the parent widget works most stably, and that is what I have opted to implement.

What happens if I:

• Set the parent to Red
• Set the child to Transparent
• Set the parent to Blue?

My read of this code is that the child will end up with a red background. Don't we also need to propagate any background color to all children?

Also - what about alpha blending? The approach you've described will only work for a true TRANSPARENT color. If I set my background to "50% gray, 50% alpha", and my parent is red, then my background shouldn't be red - it should be a 50% blend of gray and red.

This last case is definitely more complex to handle (although, interestingly, a blend with TRANSPARENT should be a redundant case of blending with any parent color...). Unless you can find an easy way to implement it, I'd be OK with noting this as an edge case in the docs.

Another bug I have noticed is that when a button's background_color is manually set to another color, like in the above image, then a white border appears. Maybe it is not clearly visible in a white background, but if we change the background to a contrasting color, then it becomes apparent.
...
But then, it doesn't look like a native button anymore.

A red background doesn't look very native either :-) There's an argument to be made that the border is desirable specifically because it ensures the button edge is visually distinct. If I have a red background and a red button, how do I know the extent of the button's pressable surface?

As for the new failing canvas tests:

tests/widgets/test_canvas.py::test_background_color_transparent
tests/widgets/test_canvas.py::test_transparency

They are somehow connected to the new set_background_color() method of Box widget, as when I disable the set_background_color() method of Box widget, the error disappears.

Well sure - you're messing around with transpareny, so the tests of transparency are breaking. My guess will be either the expected results are incorrect once you correctly handle transparency, or the canvas probe isn't correctly introspecting transparency.

[proneon267]

Apologies for the delayed response - I had gotten busy with my university assignments.

I've addressed background color and transparency issues across all widgets, eliminating the need of _background_supports_alpha and background_supports_alpha.

Additionally, I've ensured proper handling of rgba() for setting background colors, replicating CSS's rgba handling with alpha compositing. Tests and probes have been fixed, and I've double-checked my equations. I've also prepared a sample app to compare WinForms' background color implementation with CSS's:

"""
My first application
"""

import toga
from toga.style import Pack
from toga.colors import rgba


class HelloWorld(toga.App):
    def validate_rgba(self, value):
        try:
            parts = value.split(",")
            if len(parts) != 4:
                raise ValueError
            r, g, b, a = map(float, parts)
            if not (0 <= r <= 255 and 0 <= g <= 255 and 0 <= b <= 255 and 0 <= a <= 1):
                raise ValueError
        except ValueError:
            print("Invalid RGBA string format. Example: 0,255,0,0.5")
        return None

    def do_change_place(self, widget, **kwargs):
        color_tuple = tuple(map(float, self.color_input.value.split(",")))
        self.widget_box.style.background_color = rgba(*color_tuple)

        if getattr(self, "widgets_in_upper_box", True):
            self.lower_box.add(self.widget_box)
            self.widgets_in_upper_box = False
        else:
            self.upper_box.add(self.widget_box)
            self.widgets_in_upper_box = True

    def startup(self):
        self.main_window = toga.MainWindow(title=self.formal_name)
        self.toga_box = toga.Box(style=Pack(flex=1, direction="column"))

        self.upper_box = toga.Box(style=Pack(flex=1, background_color="red"))
        self.lower_box = toga.Box(style=Pack(flex=1, background_color="blue"))

        self.widget_box = toga.Box(
            style=Pack(height=60, flex=1, background_color=rgba(21, 21, 21, 0.6))
        )
        self.button = toga.Button(
            text="Change Place",
            on_press=self.do_change_place,
            style=Pack(
                padding=10,
                padding_top=15,
                padding_right=5,
                background_color="transparent",
            ),
        )
        self.label = toga.Label(
            text="WinForms RGBA:",
            style=Pack(
                padding_top=20,
                padding_bottom=20,
                color="white",
                background_color="transparent",
            ),
        )
        self.color_input = toga.TextInput(
            placeholder="21,21,21,0.6",
            value="21,21,21,0.6",
            validators=[self.validate_rgba],
            style=Pack(padding_top=15, padding_left=5),
        )
        self.widget_box.add(self.button, self.label, self.color_input)

        self.upper_box.add(self.widget_box)

        self.toga_box.add(self.upper_box, self.lower_box)
        self.web_box = toga.Box(
            style=Pack(flex=1),
            children=[
                toga.WebView(
                    url="https://proneon267.github.io/proneon267-tests/transparency-test.html",
                    style=Pack(flex=1),
                )
            ],
        )

        self.main_window.content = toga.SplitContainer(
            content=[self.toga_box, self.web_box]
        )
        self.main_window.show()

        self.widget_box.refresh()


def main():
    return HelloWorld()

The WebView HTML file can be found https://proneon267.github.io/proneon267-tests/transparency-test.html. Please try out the sample app and let me know if you encounter any inconsistencies.

Based on this, it's evident that the expected reference image of the canvas is incorrect and requires updating.

I haven't made TRANSPARENT the default value for background_color yet, as I want to fix the implementations across all backends first.

[freakboy3742]

The core of the Winforms transparency changes make sense; I've flagged a couple of issues inline.

It doesn't surprise me that the reference image needs to be changed. When the test fails locally, it will save a copy of the "actual" image. The log of the test failure should provide the image that's been generated; the image generated in CI is also uploaded as an artefact attached to the CI run.

The biggest issue at this point is the new android "warning" branch, and the test that you've added to get coverage - the approach you've taken seems to be the "make the test be quiet" approach, rather than actually attempting to understand what is going on, and why that branch isn't being covered (and, more importantly - why it was covered before).

There's also an issue with the way you've implemented the background color probe; details inline.

[freakboy3742]

This shouldn't be an explicit type check for Box. self.interface.children is None is a better check for widgets that cannot have children; if children is not None, then there are children to work with.

[freakboy3742]

toga_color is also a method, so there's an inherent ambiguity here.

[freakboy3742]

The use of child and parent nomenclature here presupposes the usage. Alpha blending is a generic task; back and front (or similar) would be better terminology.

I'd also be inclined to add this as a utility in core (or possibly even in Travertino). Although we're not actually using this anywhere other than Winforms, the generic ability to do alpha blending isn't a bad thing to have, and it would allow us to explicitly test the blending API with core tests, rather than implicitly testing it through usage in Winforms.

[freakboy3742]

Code comments generally shouldn't refer to the author. We're describing the current state of the code, which isn't dependent on any one author.

[freakboy3742]

This branch is dealing with setting the color on the root element (i.e, parent is None); what happens if color has an alpha value (i.e., set the background color of the root element to 0.5 opacity red)? Do we need to do an alpha blend with SystemColors.Control?

[freakboy3742]

Again - this requires that parent exists.

[freakboy3742]

As above - the value of background_color shouldn't matter; we're trying to establish ground truth.

[freakboy3742]

This doesn't make any sense to me. Why couldn't the background be obtained?

[freakboy3742]

As with the comment on the implementation - why is this occurring? Why is the test suite passing with 100% branch coverage prior to this change?

[freakboy3742]

This probably needs to be broken up into a couple of release notes - one for each underlying issue that we're resolving.

[proneon267]

I've identified the cause of the missing coverage on the Android canvas:

The missing coverage surfaced after I had made the following change:

toga/android/src/toga_android/widgets/base.py

Lines 138 to 142 in a9f9716

	if not hasattr(self, "_default_background"):
	self._default_background = self.native.getBackground()
	if value in (None, TRANSPARENT):
	self.native.setBackground(self._default_background)

to:

toga/android/src/toga_android/widgets/base.py

Lines 138 to 144 in c767a5b

	if not hasattr(self, "_default_background"):
	self._default_background = self.native.getBackground()
	if value is None:
	self.native.setBackground(self._default_background)
	elif value is TRANSPARENT:
	self.native.setBackgroundColor(Color.TRANSPARENT)

The missing coverage was reported for the lines 245->247:

toga/android/src/toga_android/widgets/canvas.py

Lines 244 to 247 in a9f9716

	background = self.native.getBackground()
	if background:
	background.draw(canvas)
	self.native.draw(canvas)

It seemed that a test was setting the widget's background to None, causing it to skip over the if statement. This resulted in coverage for the case of a direct jump to line 247. However, when I changed set_background_simple to set the background color to Color.TRANSPARENT, the background was never None, so it never directly jumped to line 247. As a result, coverage now complains about missing coverage for the case of a direct jump to line 247.

The test that is covering the case of direct jump to line 247 is test_transparency:

toga/testbed/tests/widgets/test_canvas.py

Lines 283 to 303 in a9f9716

	async def test_transparency(canvas, probe):
	"Transparency is preserved in captured images"
	canvas.style.background_color = TRANSPARENT
	# Draw a rectangle. move_to is implied
	canvas.context.begin_path()
	canvas.context.rect(x=20, y=20, width=120, height=120)
	canvas.context.fill(color=REBECCAPURPLE)
	canvas.context.begin_path()
	canvas.context.rect(x=60, y=60, width=120, height=120)
	canvas.context.fill(color=rgba(0x33, 0x66, 0x99, 0.5))
	await probe.redraw("Image with transparent content and background")
	# 0.1 is a big threshold; it's equivalent to 400 pixels being 100% the wrong color.
	# This occurs because pixel aliasing around the edge of the squares generates
	# different colors due to image scaling and alpha blending differences on each
	# platform. You could also generate 0.1 threshold error by moving the entire image 1
	# px to the left. However, it's difficult to find a measure that passes the edge
	# issue without also passing a translation error.
	assert_reference(probe, "transparency", threshold=0.1)

At the end of this test, we do:

toga/testbed/tests/widgets/test_canvas.py

Line 303 in a9f9716

assert_reference(probe, "transparency", threshold=0.1)

And in assert_reference we do:

toga/testbed/tests/widgets/test_canvas.py

Lines 241 to 244 in a9f9716

	def assert_reference(probe, reference, threshold=0.0):
	"""Assert that the canvas currently matches a reference image, within an RMS threshold"""
	# Get the canvas image.
	image = probe.get_image()

So, for a canvas widget, it calls get_image()=>get_image_data() and in Canvas.get_image_date():

toga/android/src/toga_android/widgets/canvas.py

Lines 244 to 247 in a9f9716

	background = self.native.getBackground()
	if background:
	background.draw(canvas)
	self.native.draw(canvas)

Here, background = self.native.getBackground() returned None and it directly jumped to line 247

I have also identified that, in base.py=>set_background_simple:

toga/android/src/toga_android/widgets/base.py

Line 139 in a9f9716

self._default_background = self.native.getBackground()

Here, self.native.getBackground() returned None since there was no background previously set on the widget.

So, to account for the missing coverage of the background color being set to None, should we introduce a new test test_background_color_none similar to test_background_color_transparent?

[proneon267]

Quick question, if I move the fixes, I have made to the Android backend to a separate PR(like "Android background_color fixes") and change the description of this PR, then can we merge this PR?

Also, a meta question, often times when working on a PR, I encounter several related bugs that I can fix. But by doing so, I increase the size of the PR. Moreover, if I decide to breakdown each of those bugfixes into new PRs, then I just start to pile up PRs. What should I do in such situations? Do I log an issue about each of those bugs & not fix the bugs, and leave it at that?

[freakboy3742]

Quick question, if I move the fixes, I have made to the Android backend to a separate PR(like "Android background_color fixes") and change the description of this PR, then can we merge this PR?

I still need to do a thorough review; but reducing the scope of a PR will always make it more likely it will be merged. Without doing that full review, it's difficult to say whether "this PR minus Android" would be mergable.

Also, a meta question, often times when working on a PR, I encounter several related bugs that I can fix. But by doing so, I increase the size of the PR. Moreover, if I decide to breakdown each of those bugfixes into new PRs, then I just start to pile up PRs. What should I do in such situations? Do I log an issue about each of those bugs & not fix the bugs, and leave it at that?

The PRs only "pile up" when they're not presented in a mergable state. The smaller they are, the more likely they will be mergable - or, at least, the easier it will be to review them, or modify them so they are mergable.

"One PR == one issue" is a good general rule to work by. If, in the process of fixing one bug, you find a second issue - submit a second PR. You don't necessarily need to open a second issue - you can if you want to, but we're happy to have a PR with no attached issue, as long as the PR contains as much detail as the issue would have had (i.e, how do I reproduce this problem).

The only real reason that a single PR would close multiple issues is if fixing the second issue is almost accidental - that there's some fundamental conceptual fix, and one fix corrects 2 (seemly unrelated) things. However, if the fix for the second issue can be completely isolated from fix for the first issue - make it a second PR. The same is true of features - unless 2 features are absolutely co-mingled, present them as 2 PRs, not 1.

The reason this PR is taking so long to land? It's not one issue. Based purely on the change notes, it's at least 7 issues. Every time it's come back for review, it's acquired a couple more issues, and more complexity. That's why I've previously advised - twice - that this PR needs to be broken up.

This complexity also impacts on when I'm able to provide a review. If I were to provide a full review of this PR right now, I'd need to set aside half a day. My final review will involve require running an example of almost every widget on every platform, to verify that there hasn't been a change to background color rendering (or, if there is a change, that it's both intentional and desired).

That's a big commitment - and I need to balance scheduling that review against my other priorities - which impacts on the feedback cycle that you get. And, to be completely frank, based on past PRs you've submitted, I'd honestly expect that I'd need to do another half day review in a day/week/month when you've been able to respond to the feedback that has been provided.

Compare that to a small PR for a clearly described issue that touches a handful of files? I can slip a review of that in at the end of the day when I've got 20 minutes to spare. If I need to review that same PR twice or three times in a week, that's not especially onerous, as long as progress is being made. And, from your perspective, it means you can take lessons learned landing one PR into the next one, on a much faster feedback cycle. You could easily end up landing 7 PRs in 7 weeks, each of which received multiple passes of review - because you've made the reviewing process easier.

To be clear - this isn't just a rule I'm making up solely for you, either. It's the sort of thing I have to do as well. Consider #2244 - that PR turned into a prototyping monster; I'm currently in the process of converting it into ~10 PRs, each of which gets one step closer to the final result. This has been done entirely because of the overhead of code review.

[proneon267]

I understand the importance of keeping my PRs small and focused, and I appreciate your patience and guidance. Regarding the current PR, I'll take your advice and break it down into smaller, more manageable and reviewable PRs.

To avoid piling up unmerged PRs, I'll also focus on ensuring each submission is in a mergeable state before moving on to the next.

I understand that large PRs demand substantial review time and can complicate the merging process. I'll start by addressing the current PR, breaking it down as discussed - starting with the smallest bugfix in this PR.

Thank you again for your guidance and support. I really appreciate it.

[mhsmith]

if I set a background color on the parent like:

toga.Box(
            style=Pack(flex=1, background_color="#87CEFA"),
            children=[
                toga.Selection(
                    items=["Alice", "Bob", "Charlie"],
                )
            ],
        )

Then the animation effect on interaction would look like:

As we can see, the dropdown arrow is not visible, and the ripple effect is also not visible. Further, the widget doesn't set any background color and hence even setting the parent's background color also destroys the native effects.

I can confirm that this also happens Toga 0.4.5, so it wasn't introduced by any of the other changes in this PR. if we can understand exactly why the problem is happening, then we'll have a better idea of whether this is the simplest solution.

Widgets shouldn't even be aware of their parent's background. But in this case, the Box isn't actually the Selection's parent at the native level: both of them are direct children of the RelativeLayout, and the Box appears behind the Selection because of their order of creation. So maybe certain background features are being drawn directly on the native parent (the RelativeLayout), and the intervening Box is covering it up? Experimenting with semi-transparent backgrounds may answer this.

It may also have something to do with elevation.

[proneon267]

Thanks for confirming. I'll investigate further and report back.

[proneon267]

Can you take a look at the iOS testbed setup failure: https://github.com/beeware/toga/actions/runs/12103501801/job/33745775230?pr=2484. It is failing to build Pillow for iOS.

[freakboy3742]

@proneon267 It shouldn't be trying to compile Pillow at all - it should be using a pre-compiled wheel. From the look of it, the issue was a timeout on the BeeWare wheel repo; I've restarted the build, and that seems to have corrected the problem.

[proneon267]

Thanks for restarting it.