WinForms `background_color` Transparency Fixes #2484

proneon267 · 2024-04-06T07:22:14Z

Refs #767, Fixes #2425, Fixes #2430

This PR fixes transparency issues and rgba() interpretation of background_color on winforms.
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.

Status of transparency tests: #3015

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 · 2024-04-06T20:10:47Z

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 · 2024-04-07T05:15:36Z

android/src/toga_android/widgets/canvas.py

@@ -236,14 +237,20 @@ def _text_paint(self, font):
        paint.setTextSize(self.scale_out(font.size()))
        return paint

+    # This has been separated out, so that it can be mocked during testing.
+    def _native_get_background(self):
+        return self.native.getBackground()


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.

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?

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?

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 · 2024-04-07T05:31:12Z

testbed/tests/widgets/properties.py

+    # Set the background color to something different
+    widget.style.background_color = RED
+    await probe.redraw("Widget background color should be RED")
+    assert_color(probe.background_color, named_color(RED))


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?

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 · 2024-04-07T12:58:47Z

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 · 2024-04-07T15:37:41Z

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 · 2024-04-07T23:25:06Z

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 · 2024-04-09T16:05:28Z

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 · 2024-04-09T23:59:20Z

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 · 2024-04-13T14:49:19Z

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 · 2024-04-15T02:43:04Z

winforms/src/toga_winforms/widgets/base.py

+            else:
+                self.native.BackColor = native_color(color)
+
+        if isinstance(self.interface, toga.Box):


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 · 2024-04-15T02:43:48Z

winforms/src/toga_winforms/colors.py

        )
-        CACHE[c] = color
+        CACHE[toga_color] = color


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

freakboy3742 · 2024-04-15T02:46:27Z

winforms/src/toga_winforms/colors.py

+    return rgba(native_color.R, native_color.G, native_color.B, native_color.A / 255)
+
+
+def alpha_blending_over_operation(child_color, parent_color):


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 · 2024-04-15T02:48:10Z

winforms/src/toga_winforms/colors.py

+
+
+def alpha_blending_over_operation(child_color, parent_color):
+    # The blending operation I have implemented here is the "over" operation and


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 · 2024-04-15T02:52:59Z

winforms/src/toga_winforms/widgets/base.py

+                )
+                self.native.BackColor = native_color(blended_color)
+            else:
+                self.native.BackColor = native_color(color)


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 · 2024-04-15T03:07:11Z

winforms/tests_backend/widgets/base.py

            return TRANSPARENT
        else:
-            return toga_color(self.native.BackColor)
+            parent_color = toga_color(self.widget.parent._impl.native.BackColor)


Again - this requires that parent exists.

freakboy3742 · 2024-04-15T03:08:15Z

winforms/tests_backend/widgets/base.py

+            parent_color = toga_color(self.widget.parent._impl.native.BackColor)
+            blended_color = alpha_blending_over_operation(
+                self.widget.style.background_color, parent_color
+            )


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

freakboy3742 · 2024-04-15T03:23:05Z

android/src/toga_android/widgets/canvas.py

@@ -244,6 +245,8 @@ def get_image_data(self):
        background = self.native.getBackground()
        if background:
            background.draw(canvas)
+        else:
+            warnings.warn("Failed to get canvas background")


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

freakboy3742 · 2024-04-15T03:25:35Z

android/tests_backend/widgets/canvas.py

+        self.native.setBackground(None)
+        with pytest.warns(match="Failed to get canvas background"):
+            self.impl.get_image_data()
+        self.native.setBackground(original_background)


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 · 2024-04-15T03:45:17Z

changes/2484.bugfix.rst

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

proneon267 · 2024-04-23T17:27:02Z

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 · 2025-01-23T09:23:05Z

Here is the current state:

Example source:

import toga
from toga.style import Pack
from toga.style.pack import COLUMN

class HelloWorld(toga.App):
    def reset_to_native_default_background_color(self, widget, **kwargs):
        for widget in self.widgets:
            del widget.style.background_color
        self.content.refresh()

    def startup(self):
        """Construct and show the Toga application.

        Usually, you would add your application to a main content box.
        We then create a main window (with a name matching the app), and
        show the main window.
        """
        self.content = toga.Box(
            style=Pack(
                background_color="#87CEFA",
                direction=COLUMN,
                flex=1,
            ),
            children=[
                toga.Box(style=Pack(flex=1.5)),
                toga.Button(
                    text="Reset to native default background color",
                    on_press=self.reset_to_native_default_background_color,
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.ImageView(
                    toga.Image(self.paths.app / "resources/imageview.png"),
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.Label(text="Label"),
                toga.Box(style=Pack(flex=1.5)),
                toga.ProgressBar(max=100, value=50),
                toga.Box(style=Pack(flex=1.5)),
                toga.Selection(items=["Alice", "Bob", "Charlie"]),
                toga.Box(style=Pack(flex=1.5)),
                toga.Slider(min=-5, max=10, value=7),
                toga.Box(style=Pack(flex=1.5)),
                toga.NumberInput(value=8908),
                toga.Box(style=Pack(flex=1.5)),
                toga.MultilineTextInput(
                    value="Some text.\nIt can be multiple lines of text."
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.TextInput(value="Jane Developer"),
                toga.Box(style=Pack(flex=1.5)),
                toga.Switch(text="Switch"),
                toga.Box(style=Pack(flex=1.5)),
                toga.DetailedList(
                    data=[
                        {
                            "icon": toga.Icon("icons/arthur"),
                            "title": "Arthur Dent",
                            "subtitle": "Where's the tea?",
                        },
                        {
                            "icon": toga.Icon("icons/ford"),
                            "title": "Ford Prefect",
                            "subtitle": "Do you know where my towel is?",
                        },
                        {
                            "icon": toga.Icon("icons/tricia"),
                            "title": "Tricia McMillan",
                            "subtitle": "What planet are you from?",
                        },
                    ],
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.DateInput(),
                toga.Box(style=Pack(flex=1.5)),
                toga.TimeInput(),
            ],
        )
        self.main_window = toga.MainWindow(title=self.formal_name)
        self.main_window.content = toga.ScrollContainer(content=self.content)
        self.main_window.show()


def main():
    return HelloWorld()

freakboy3742 · 2025-01-24T03:16:58Z

I'm not sure if this was intended for review - but the background colors here look inconsistent. Some of the widgets (selection, dateinput, timeinput) are using a white background; some are using a transparent background (table, textinput, numberinput), and progress bar appears transparent... but to the base of the window, not the box.

freakboy3742 · 2025-01-24T03:18:19Z

Also - could I ask you to audit the Fixes annotations in the ticket title. When this was a "fix all background transparency" ticket, it was definitely a fix for all the issues described; but by changing it to a Winforms only ticket, those issues won't be fixed unless they were specifically Windows issues.

proneon267 · 2025-01-24T03:45:02Z

I'm not sure if this was intended for review - but the background colors here look inconsistent. Some of the widgets (selection, dateinput, timeinput) are using a white background; some are using a transparent background (table, textinput, numberinput), and progress bar appears transparent... but to the base of the window, not the box.

For Selection: BackgroundColor only affects the option list of the Selection widget:

For DateInput and TimeInput: Winforms ignores native.BackgroundColor, and so the background color of these widgets cannot be changed.

and progress bar appears transparent... but to the base of the window, not the box.

I am not sure if I understood what you meant, but here is what it looks like without other widgets:

self.content = toga.Box(
    style=Pack(
        background_color="#87CEFA",
        direction=COLUMN,
        flex=1,
    ),
    children=[
        toga.Box(style=Pack(flex=1.5)),
        toga.ProgressBar(max=100, value=50),
        toga.Box(style=Pack(flex=1.5)),
    ],
)

Also - could I ask you to audit the Fixes annotations in the ticket title. When this was a "fix all background transparency" ticket, it was definitely a fix for all the issues described; but by changing it to a Winforms only ticket, those issues won't be fixed unless they were specifically Windows issues.

I have updated the ticket description and removed any mentions of unrelated backends. Since, the linked issues: #767, #2425, #2430, are all related to winforms' background_color bugs, so I have kept them.

proneon267 · 2025-01-24T04:18:11Z

Here is what making TRANSPARENT as the default background looks like, for NumberInput, TextInput, MultilineInput, PasswordInput:

If this looks correct, then I will make TRANSPARENT as the default background looks like, for NumberInput, TextInput, MultilineInput, PasswordInput

freakboy3742 · 2025-01-24T04:54:33Z

For Selection: BackgroundColor only affects the option list of the Selection widget:
...
For DateInput and TimeInput: Winforms ignores native.BackgroundColor, and so the background color of these widgets cannot be changed.

The features supported by the widget isn't the point of contention. It's that the background colors aren't consistent with "default" behavior. The default appearance on a TextInput should match the default background on a DateInput, since they're both "text fields".

and progress bar appears transparent... but to the base of the window, not the box.

I am not sure if I understood what you meant, but here is what it looks like without other widgets:

What I'm saying is that the "non active" region of the progress bar is the same light grey color as the background that is now being used by TextInput etc - which doesn't appear consistent with other widgets.

Here is what making TRANSPARENT as the default background looks like, for NumberInput, TextInput, MultilineInput, PasswordInput:
...
If this looks correct, then I will make TRANSPARENT as the default background looks like, for NumberInput, TextInput, MultilineInput, PasswordInput

That definitely doesn't look correct as a default.

The fact that DateInput doesn't honor the background color change suggests to me that whatever color it is using (presumably some sort of "default input background" color), that is what the default should be.

The thing to keep in mind in all of this - the default Toga colors should be identical to what is generated if you make no manual changes to color at all. A user who is manually changing colors in their app is almost certainly making a mistake from an app design perspective. Toga supports color and background color style options under duress. But if we're going to support them, an app that does the right thing and doesn't use any color options should have an app that does not change the look and feel of the widget at all. Absent of a specific color change directive, the color that the widget renders out of the box is the correct color.

Also - could I ask you to audit the Fixes annotations in the ticket title. When this was a "fix all background transparency" ticket, it was definitely a fix for all the issues described; but by changing it to a Winforms only ticket, those issues won't be fixed unless they were specifically Windows issues.

I have updated the ticket description and removed any mentions of unrelated backends. Since, the linked issues: #767, #2425, #2430, are all related to winforms' background_color bugs, so I have kept them.

#767 is most definitely not a winforms specific issue. It was originally reported on winforms, but it's tagged Android/macOS/Linux/Windows, and until a week or so ago, was tagged iOS as well - because the issue is transparency handling on Box. It's arguable whether #2425 is - it's definitely framed as a Winforms bug, but it could be a duplicate of #767.

proneon267 · 2025-01-24T14:42:24Z

The features supported by the widget isn't the point of contention. It's that the background colors aren't consistent with "default" behavior. The default appearance on a TextInput should match the default background on a DateInput, since they're both "text fields".

That definitely doesn't look correct as a default.

The fact that DateInput doesn't honor the background color change suggests to me that whatever color it is using (presumably some sort of "default input background" color), that is what the default should be.

The thing to keep in mind in all of this - the default Toga colors should be identical to what is generated if you make no manual changes to color at all. A user who is manually changing colors in their app is almost certainly making a mistake from an app design perspective. Toga supports color and background color style options under duress. But if we're going to support them, an app that does the right thing and doesn't use any color options should have an app that does not change the look and feel of the widget at all. Absent of a specific color change directive, the color that the widget renders out of the box is the correct color.

I agree with you, hence I have changed it so that unless a widget specifically defines its default_background_color, the system assigned background color will be its default_background_color.

What I'm saying is that the "non active" region of the progress bar is the same light grey color as the background that is now being used by TextInput etc - which doesn't appear consistent with other widgets.

It turns out, ProgressBar also doesn't respond to BackColor, so I have removed TRANSPARENT as the default background color on ProgressBar.

Here is the current state after the changes:

Example source:

import toga
from toga.style import Pack
from toga.style.pack import COLUMN


class HelloWorld(toga.App):
    def reset_to_native_default_background_color(self, widget, **kwargs):
        for widget in self.widgets:
            del widget.style.background_color
        self.content.refresh()

    def startup(self):
        """Construct and show the Toga application.

        Usually, you would add your application to a main content box.
        We then create a main window (with a name matching the app), and
        show the main window.
        """
        self.content = toga.Box(
            style=Pack(
                background_color="#87CEFA",
                direction=COLUMN,
                flex=1,
            ),
            children=[
                toga.Box(style=Pack(flex=1.5)),
                toga.Button(
                    text="Reset to native default background color",
                    on_press=self.reset_to_native_default_background_color,
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.ImageView(
                    toga.Image(self.paths.app / "resources/imageview.png"),
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.Label(text="Label"),
                toga.Box(style=Pack(flex=1.5)),
                toga.ProgressBar(max=100, value=50),
                toga.Box(style=Pack(flex=1.5)),
                toga.Selection(items=["Alice", "Bob", "Charlie"]),
                toga.Box(style=Pack(flex=1.5)),
                toga.Slider(min=-5, max=10, value=7),
                toga.Box(style=Pack(flex=1.5)),
                toga.NumberInput(value=8908),
                toga.Box(style=Pack(flex=1.5)),
                toga.MultilineTextInput(
                    value="Some text.\nIt can be multiple lines of text."
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.TextInput(value="Jane Developer"),
                toga.Box(style=Pack(flex=1.5)),
                toga.PasswordInput(value="Jane"),
                toga.Box(style=Pack(flex=1.5)),
                toga.Table(
                    headings=["Name", "Age"],
                    data=[
                        ("Arthur Dent", 42),
                        ("Ford Prefect", 37),
                        ("Tricia McMillan", 38),
                    ],
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.Switch(text="Switch"),
                toga.Box(style=Pack(flex=1.5)),
                toga.DetailedList(
                    data=[
                        {
                            "icon": toga.Icon("icons/arthur"),
                            "title": "Arthur Dent",
                            "subtitle": "Where's the tea?",
                        },
                        {
                            "icon": toga.Icon("icons/ford"),
                            "title": "Ford Prefect",
                            "subtitle": "Do you know where my towel is?",
                        },
                        {
                            "icon": toga.Icon("icons/tricia"),
                            "title": "Tricia McMillan",
                            "subtitle": "What planet are you from?",
                        },
                    ],
                ),
                toga.Box(style=Pack(flex=1.5)),
                toga.DateInput(),
                toga.Box(style=Pack(flex=1.5)),
                toga.TimeInput(),
                toga.Box(style=Pack(flex=1.5)),
            ],
        )
        self.main_window = toga.MainWindow(title=self.formal_name)
        self.main_window.content = toga.ScrollContainer(content=self.content)
        self.main_window.show()


def main():
    return HelloWorld()

Without any background color on the root(`self.content`) `Box`	With a background color on the root(`self.content`) `Box`

Now, only the following widgets set their default background as TRANSPARENT:

toga.Box()
toga.ImageView()
toga.Label()
toga.Slider()
toga.Switch()

freakboy3742

Getting closer; a few notes inline. Also drawing your attention to ensuring that all previous review comments have been addressed before asking for another review.

changes/2484.bugfix.1.rst

changes/2484.bugfix.2.rst

freakboy3742 · 2025-01-28T02:20:10Z

changes/2484.bugfix.2.rst

This should be 2425.bugfix.rst - it's a reference to a specific known bug.

freakboy3742 · 2025-01-28T02:46:40Z

winforms/src/toga_winforms/widgets/canvas.py

+    def set_background_color(self, color):
+        if color in {None, TRANSPARENT}:
+            # BackColor needs to be set to Color.Transparent or else the
+            # image captured by get_image_data() won't have transparency.


So - this comment is technically correct, but doesn't help explain the problem as much as it could.

When I saw this, I initially thought "why isn't this _default_background_color = TRANSPARENT?" - but then worked out that would result in blending the background color, which is what we need to avoid. Drawing the direct connection to the blending behavior would be helpful here.

However, it does make me wonder if we need to also set _default_background_color = TRANSPARENT (or possibly some other edge case handling here). If I set the background color of the canvas to "Red with 50% Alpha" - the image should be red with 50% alpha... but this will fall back to the default blending for the background, so it will be visually mixed with the grey control default color. Is there any way we can get both outcomes here? Or is this just going to have to be a platform quirk (one that should be documented).

On further testing of the Canvas widget's background color, I think we have hit a fork in the road, and we need to choose between showing the correct alpha blended canvas background color on the app or preserving the transparency on the exported canvas image.

For the example code of Toga Tutorial 4:

# Create empty canvas self.canvas = toga.Canvas( style=Pack( flex=1, background_color=rgba(0, 255, 0, 0.5), width=200, height=250, ), on_resize=self.on_resize, on_press=self.on_press, ) box = toga.Box( style=Pack( background_color=rgba(0, 0, 255, 1), width=400, height=400, ), children=[self.canvas], ) # Add the content on the main window self.main_window.content = box

We get the following results(Click to zoom the images):

(1) Without manual alpha blending of the canvas background i.e.,
def set_background_color(self, color): self.native.BackColor = native_color(color)

(2) With manual alpha blending of the canvas background i.e.,
def set_background_color(self, color): if color in {None, TRANSPARENT}: self.native.BackColor = Color.Transparent else: super().set_background_color(color)

As we can see in (1), the exported canvas image has a transparency to it, but the canvas background color in the app is wrong. In (2), although the canvas background color in the app is correct, however the exported canvas image has lost its transparency. So, we need to choose which one to keep.

There is also another option:

(3) Use (2), but before exporting the canvas image, set the background color to `Color.Transparent` i.e.,
def get_image_data(self): + current_background = self.native.BackColor + self.native.BackColor = Color.Transparent + width, height = (self.native.Width, self.native.Height) bitmap = Bitmap(width, height) rect = Rectangle(0, 0, width, height) graphics = Graphics.FromImage(bitmap) graphics.Clear(self.native.BackColor) self.native.OnPaint(WinForms.PaintEventArgs(graphics, rect)) + + self.native.BackColor = current_background stream = MemoryStream() bitmap.Save(stream, ImageFormat.Png) return bytes(stream.ToArray())

The exporting of canvas image, having TRANSPARENT or opaque background could be controlled by specifying an additional parameter to `get_image_data(export_with_transparent_background=True)`.

On further testing of the Canvas widget's background color, I think we have hit a fork in the road, and we need to choose between showing the correct alpha blended canvas background color on the app or preserving the transparency on the exported canvas image.
...
There is also another option:

(3) Use (2), but before exporting the canvas image, set the background color to Color.Transparent i.e.,

(3) seems like the best candidate - with 2 possible caveats:

Does this cause a "flash" as the background color is switched and then switched back in rapid succession? If so, can we avoid that flash by explicitly calling SuspendLayout() on the canvas?

Instead of switching in a temporary TRANSPARENT color, shouldn't this be a temporary "actual background color as defined" value? Based on the example code, the screenshot should have a background of "50% transparent green", not fully transparent.

I modified (3) by applying your suggestions, and the result was a success:

def get_image_data(self): + self.native.SuspendLayout() + current_background_color = self.interface.style.background_color + self.native.BackColor = native_color(current_background_color) width, height = (self.native.Width, self.native.Height) bitmap = Bitmap(width, height) rect = Rectangle(0, 0, width, height) graphics = Graphics.FromImage(bitmap) graphics.Clear(self.native.BackColor) self.native.OnPaint(WinForms.PaintEventArgs(graphics, rect)) stream = MemoryStream() bitmap.Save(stream, ImageFormat.Png) + self.set_background_color(current_background_color) + self.native.ResumeLayout() return bytes(stream.ToArray())

freakboy3742 · 2025-01-28T02:48:36Z

winforms/src/toga_winforms/widgets/base.py

+            # If a widget hasn't specifically defined a default background color then
+            # set the system assigned background color as the default background color
+            # of the widget.
+            self._default_background_color = toga_color(self.native.BackColor)


Three notes here:

If we're doing this, it should be hasattr not getattr is None

"if not set" seems an inelegant approach - why not set _default_background_color before calling create, and then overwrite it in create() when required? That way we know it will always be set to a value.

Are there any "dark mode" implications here? Should we not use None as the default value, and defer evaluation until the default value is used (and then ensure colors are re-applied when the color mode changes?)

If we're doing this, it should be hasattr not getattr is None

Thanks I have changed it.

"if not set" seems an inelegant approach - why not set _default_background_color before calling create, and then overwrite it in create() when required? That way we know it will always be set to a value.

The self.native object is set after the call to create(), so we cannot set _default_background_color before calling create()

Are there any "dark mode" implications here? Should we not use None as the default value, and defer evaluation until the default value is used (and then ensure colors are re-applied when the color mode changes?)

Since, by default pythonnet uses .NET Framework 4.8.1, and winforms dark mode is available as an experimental feature only in .NET Core 9: dotnet/winforms#11857, so we can ignore dark mode until we upgrade to a recent version of .NET Core.

Sidenote: Btw, I have found a way to specify pythonnet to use the latest installed .NET Core version. This would allow us to access a bunch of new features in winforms(like multiple Folder Selection dialog without requiring anything extra). I will make an issue describing the process, after completing my PRs.

freakboy3742 · 2025-01-28T03:11:29Z

winforms/src/toga_winforms/colors.py

+    return rgba(c.R, c.G, c.B, c.A / 255)
+
+
+def alpha_blending_over_operation(front_color, back_color):


As noted in a prior review, I'd be inclined to move this to toga.core at the very least, and possibly to Travertino (which is a lot easier now that Travertino is in the Toga repo and version locked with Toga). Color is a class in travertino; mycolor.blend_over(some_other_color) makes sense as a high level API, even if it's only being used by Windows in practice.

If nothing else, it would provide a place to test the blending math. Right now, we're only testing that math implicitly.

Sure, I will move it there and report back.

Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>

proneon267 added 6 commits April 5, 2024 06:48

Fixed transparency related bugs

1e75114

Minor tweaks

1e075fa

Fixed cocoa table widget

ca50f58

Added changelog

6c1aeea

Fixed test

24abf08

Fixed iOS progressbar

a94f0de

proneon267 mentioned this pull request Apr 6, 2024

Fixes Winforms Progressbar #2485

Open

4 tasks

proneon267 changed the title ~~Transparency test fixes~~ background_color Transparency Fixes Apr 6, 2024

Fixed android canvas test

c30aa56

freakboy3742 requested changes Apr 7, 2024

View reviewed changes

proneon267 added 6 commits April 7, 2024 06:08

Removed mocking from android canvas test

6fe78dd

Removed test debugging modification

4a242dd

Fixed android divider background_color

054e07b

Empty commit for CI

6b1bf9e

Fixed winforms divider implementation

4b5ed6f

Fixed winforms label transparency

77df2e9

proneon267 added 2 commits April 9, 2024 08:09

Fixed winforms box transparency

6981a7a

Fixed winforms box test

b2ca091

proneon267 added 2 commits April 13, 2024 07:14

Fixed �ackground_color and transparency on WinForms

1b3122c

Empty commit for CI

c767a5b

freakboy3742 requested changes Apr 15, 2024

View reviewed changes

proneon267 mentioned this pull request Apr 22, 2024

test_scroll fails for DetailedList & Table widgets when testbed is run locally on Android emulator #2516

Open

proneon267 and others added 6 commits January 21, 2025 08:19

Remove iOS changes

389e3eb

Merge branch 'main' into transparency_fix

96675e6

Remove iOS changes

0e633ff

Restart CI

000597e

Remove Android changes

1ab0485

Delete changes/2484.bugfix.2.rst

7b101d7

proneon267 mentioned this pull request Jan 23, 2025

Cache decoded toga color on gtk #3117

Merged

4 tasks

proneon267 added 2 commits January 22, 2025 23:18

Remove gtk changes

701baf2

Restart CI

30ceff4

proneon267 mentioned this pull request Jan 23, 2025

Android background_color Transparency Fixes #3118

Open

4 tasks

Remove unrelated changelogs

7a7ce0d

proneon267 changed the title ~~background_color Transparency Fixes~~ WinForms background_color Transparency Fixes Jan 23, 2025

Cleanup

ffa02f0

proneon267 and others added 2 commits January 24, 2025 05:38

Merge branch 'main' into transparency_fix

ef42751

Pre-commit fixes

b8d2689

preserve system assigned background as default

de424d3

proneon267 mentioned this pull request Jan 24, 2025

Remove erroneous note about _default_background_color override behavior on iOS #3125

Merged

4 tasks

proneon267 requested a review from freakboy3742 January 25, 2025 15:10

freakboy3742 requested changes Jan 28, 2025

View reviewed changes

proneon267 and others added 3 commits January 28, 2025 09:58

Apply suggestions from code review

88347d1

Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>

Apply suggestions from review

ef1a240

Fix Transparency on the exported canvas image

b6d8559

proneon267 mentioned this pull request Jan 29, 2025

Add alpha blending to Travertino #3140

Open

4 tasks

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

		return rgba(native_color.R, native_color.G, native_color.B, native_color.A / 255)


		def alpha_blending_over_operation(child_color, parent_color):



		def alpha_blending_over_operation(child_color, parent_color):
		# The blending operation I have implemented here is the "over" operation and

		return rgba(c.R, c.G, c.B, c.A / 255)


		def alpha_blending_over_operation(front_color, back_color):

WinForms background_color Transparency Fixes #2484

Are you sure you want to change the base?

WinForms background_color Transparency Fixes #2484

Conversation

proneon267 commented Apr 6, 2024 • edited by freakboy3742 Loading

proneon267 commented Apr 6, 2024

freakboy3742 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

proneon267 Apr 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

proneon267 commented Apr 7, 2024 • edited Loading

proneon267 commented Apr 7, 2024 • edited Loading

freakboy3742 commented Apr 7, 2024

proneon267 commented Apr 9, 2024 • edited Loading

freakboy3742 commented Apr 9, 2024

proneon267 commented Apr 13, 2024 • edited Loading

freakboy3742 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

proneon267 commented Apr 23, 2024 • edited Loading

proneon267 commented Jan 23, 2025 • edited Loading

freakboy3742 commented Jan 24, 2025

freakboy3742 commented Jan 24, 2025

proneon267 commented Jan 24, 2025 • edited Loading

proneon267 commented Jan 24, 2025

freakboy3742 commented Jan 24, 2025

proneon267 commented Jan 24, 2025 • edited Loading

freakboy3742 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

proneon267 Jan 28, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WinForms `background_color` Transparency Fixes #2484

WinForms `background_color` Transparency Fixes #2484

proneon267 commented Apr 6, 2024 •

edited by freakboy3742

Loading

proneon267 Apr 7, 2024 •

edited

Loading

proneon267 commented Apr 7, 2024 •

edited

Loading

proneon267 commented Apr 7, 2024 •

edited

Loading

proneon267 commented Apr 9, 2024 •

edited

Loading

proneon267 commented Apr 13, 2024 •

edited

Loading

proneon267 commented Apr 23, 2024 •

edited

Loading

proneon267 commented Jan 23, 2025 •

edited

Loading

proneon267 commented Jan 24, 2025 •

edited

Loading

proneon267 commented Jan 24, 2025 •

edited

Loading

proneon267 Jan 28, 2025 •

edited

Loading