Remove erroneous note about _default_background_color override behavior on iOS

[proneon267]

While working on #2484, I noticed that the setting of _default_background_color attribute on iOS is not correct:

toga/iOS/src/toga_iOS/widgets/base.py

Lines 8 to 18 in 25891f0

	def __init__(self, interface):
	super().__init__()
	self.interface = interface
	self._container = None
	self.constraints = None
	self.native = None
	self.create()
	# Override this attribute to set a different default background
	# color for a given widget.
	self._default_background_color = self.native.backgroundColor

Although, currently no widget on iOS is setting a different _default_background_color, but if any widget did override it, then _default_background_color would be overridden during the create() call.

But we are unconditionally setting the _default_background_color on line 18, which would discard any custom _default_background_color that may be specified by a widget.

This PR was fixing this behavior by:

toga/iOS/src/toga_iOS/widgets/base.py

Lines 8 to 19 in 29d0fd5

	def __init__(self, interface):
	super().__init__()
	self.interface = interface
	self._container = None
	self.constraints = None
	self.native = None
	self.create()
	# Override this attribute to set a different default background
	# color for a given widget.
	if getattr(self, "_default_background_color", None) is None:
	self._default_background_color = self.native.backgroundColor

However, since no widget is specifying a custom default background color, so the erroneous note was removed instead.

PR Checklist:

• 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

[freakboy3742]

So - if we have literally no widget that needs it... and the implementation has a bug anyway... why not remove the capability entirely? If we haven't found a need for it, I find it unlikely that anyone else will?

[proneon267]

I agree with you, since no widget is defining a custom default background color, so this PR changes are not required.

But we still need to save the system assigned default widget background so that we can restore it when the background color is reset.

Therefore, the only change that this PR should be doing is to remove the note which is stating that widgets can override the attribute.

I'll make the changes and report back.

[proneon267]

The webview testbed failure on iOS is unrelated, as this PR doesn't make any code changes.

[freakboy3742]

You're missing my point. We're not using the feature. So why have the feature at all?

I'm guessing your argument is that it captures the initial background color - at which point, we're back to a comment that I made during my initial review - what happens when you switch from dark mode to light mode?

The only way I can see this approach working during a mode switch is:

1. The background color is always transparent - in which case, we can use Transparent as the default value
2. The background color is always None - in which case iOS is handling the "fall back to default" value... in which case, so can we.

In either case, capturing the initial default isn't actually helping - it's just adding a state variable that gives the illusion of state without actually provide any statefulness.

[proneon267]

As you had seen in #3104, the default background color of some widgets isn't actually UIColor.clearColor or None, it's something different like UIExtendedGrayColorSpace 0 0.
Although it may seem like the system assigned default background color is just the same asUIColor.clearColor or None, but using them as the default background color will result in bugs like in #3104.

Therefore, we definitely do need to preserve the system assigned default background color. Furthermore as you have noted previously, we shouldn't be changing the system assigned default as the system assigned default is the correct default.

As for correctly handling the change from light mode to dark mode, since we are using the system assigned default background, so the system handles it correctly for us. This is also what I had confirmed from manual testing.

Therefore, we should remove the erroneous note to prevent any incorrect presumptions.

[freakboy3742]

Ok - in which case, that is the detail we should be preserving in the comment.

[proneon267]

Thank you for helping :)

[proneon267]

Webview testbed failure on iOS is unrelated.