Checkbox.fillColor should be applied to checkbox's background color when it is unchecked.

[QuncCccccc]

See https://docs.flutter.dev/release/breaking-changes/checkbox-fillColor for a migration guide

---

Fixes #123386. The fillColor should always be applied to the background color based on its definition and the border color can be customized by Checkbox.side. When the checkbox is unselected, the default fillColor should be changed to transparent now, and we assign the original fillColor value to Checkbox.side.color. When the checkbox is selected, the default fillColor is same as the original value, and the Checkbox.side.color is transparent.

Checkbox(
  fillColor: MaterialStateProperty.resolveWith((Set<MaterialState> states) {
     if (states.contains(MaterialState.selected)) {
        return Colors.orange;
     }
     return Colors.green;
  }),
  value: false, // or true to show Colors.orange
  onChanged: (bool? value) { },
),

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.

[QuncCccccc]

This will cause some scuba failures in g3. I will attach a g3fix cl/527658125 once this is merged.

[HansMuller]

Nice update. LGTM

[HansMuller]

So set activeSide(BorderSide value) { instead of this assert And the getter wouldn't need a !.

[QuncCccccc]

Got it. Fixing!

[HansMuller]

Same feedback as activeSide

[rydmike]

@QuncCccccc This PR breaks ALL past previous CheckBox theming on stable 3.10 and earlier.

On stable 3.10.5 and earlier, one my customized Checkbox themes looks like this:

Note above the tinted disable state, which also uses a custom theme for enabled state at the same time.

Optionally it can look like this when we want the colored outline in none selected mode in stable 3.10.5 and earlier.

AFTER this PR the same theming produces these results:

And:

This is a SUPER breaking feature for past Checkbox theming behavior.

[QuncCccccc]

@QuncCccccc This PR breaks ALL past previous CheckBox theming on stable 3.10 and earlier.

On stable 3.10.5 and earlier, one my customized Checkbox themes looks like this: Note above the tinted disable state, which also uses a custom theme for enabled state at the same time.

Optionally it can look like this when we want the colored outline in none selected mode in stable 3.10.5 and earlier.

AFTER this PR the same theming produces these results:

And:

This is a SUPER breaking feature for past Checkbox theming behavior.

Hi! Sorry for causing that trouble! This PR is intended to fix the fillColor behavior error because based on its definition, it should be the background color of CheckBox. So some breaking behaviors are expected. Could you attach a code sample? I can help to take a look and fix it!

[rydmike]

@QuncCccccc, thanks and yes I do agree that the fillColor does behave oddly as it was (is in stable), but on the other hand stable channel code depends on that behavior.

I will open a separate regression issue with a sample. I was working on it, but got side tracked with a nice video call with @TahaTesser.

Issue coming soon, I will tag you and ref this PR. I just found this PR when I was tracking down why it was broken when I tested on master channel.

Sure I can use the new theme props and make it work, but potentially it is a breaking change for other users as well. I don't know if others have used this theming feature as much as I have, but potentially. This does need to be documented as BREAKING change if it remains as is, with migration docs. But let's see when I post the sample and we dig into it.