Have Material widgets in a Cupertino App partially use Cupertino theme

[MitchellGoodwin]

Fixes #138621

Fixes and issue where if a Material widget is used in a Cupertino App, then some parts of it's default Material 3 theming would show up as purplish. This could be fixed by wrapping your app with a Material theme, but that's a little awkward.

Material and Cupertino themes interact with each other a little oddly. If a theme of either is searched for but does not exist, then a default one is generated. So if a Material widget is in a Cupertino app that does not already have a Material theme, then a fallback Material theme will be created. This PR makes it so that, in this case when that Material theme is created, it's default colors will be based on the Cupertino theme.

Another oddity is that a Material theme always wraps itself with a Cupertino theme that's values are based on the Material theme. So before this change, a Material widget would theoretically add a new Material based Cupertino theme to the tree. So I added logic that would have the Material theme check to see if a Cupertino theme exists, before it overwrites it.

Before:

After:

Update:
I changed it to not rely on the Material 3 flag. Instead, if a Material theme is searched for and there is already a Cupertino theme in the tree, then it will use that Cupertino theme instead of generating a new. Also, if a Material theme is searched for, and it does not find one already in the tree, but does find a Cupertino theme, then it will generate one with a color palette based off of that Cupertino theme's colors.

After with this change:

We should still probably suggest for developers to include a Material theme in their Cupertino app if they wish to use widgets from both packages.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[MitchellGoodwin]

CC @QuncCccccc @HansMuller this is a fairly simple fix, but feels like a bandaid on a larger issue. Theoretically this should make it so that if Theme.of is used inside a MaterialApp it should use Material 3 for Material widgets, but otherwise it will not. Let me know if there's a case I missed.

But this does put a bandaid on a larger issue. I was surprised to find that a Material theme will wrap itself with a Cupertino theme. So Material widgets in a Cupertino app with no Material theme ancestor will create their own Cupertino theme, regardless of there already being one, which feels gross. I did try and wrap a basic Material theme around the Cupertino app widget to copy the solution from the Material side, but that created a dependency loop. Which was almost a relief because that was ugly too. I think it is important to fix this issue with something simple like this, but ideally the two themes would be aware of each other, if not unified in some way.

[QuncCccccc]

I think this fix is smart! But not sure if this change will cause any confusion because we just made material 3 be default and then in this PR, we change the fallback to false?

[MitchellGoodwin]

I think this fix is smart! But not sure if this change will cause any confusion because we just made material 3 be default and then in this PR, we change the fallback to false?

My intention was to have Cupertino apps default to having the material 3 flag be false. And as far as I can tell, that fallback is only used when there is no theme in the tree. So it should not be used when either a MaterialApp or Theme are provided, as MaterialApp always generates a theme. Is there a case I'm missing?

[QuncCccccc]

Ah some unit tests might just build a widget without using MaterialApp or Theme, for example this one: https://github.com/flutter/flutter/pull/139145/files#diff-15ce4cd7a95566046eb6b57655b02d175a8297d14b033a5dc15fd5aa5aa866fbR209

But other than this, I also don't see any other use cases:)

[goderbauer]

I spoke to @MitchellGoodwin and he said this is still on his radar.

[MitchellGoodwin]

Converting this to a draft, as if the useMaterial3 flag gets removed in the future, then this will break. Keeping this around as a draft for the purpose of discussion.

[MitchellGoodwin]

@HansMuller this it the draft for having the themes get along. I'll add documentation recommending that developers add a Material theme to their Cupertino apps.

[QuncCccccc]

This solution makes sense to me! LGTM:) The new classes might need some more documentation.

[QuncCccccc]

LGTM：）

[QuncCccccc]

Suggested change

[auto-submit]

auto label is removed for flutter/flutter/139253, due to - The status or check suite Google testing has failed. Please fix the issues identified (or deflake) before re-applying this label.