Why do they need to be 8?

To be honest, I don't exactly know why. Something to do with BoxConstraints somewhere in the tree. All I know that if the iconSize is less than 8, this happens:

But maybe I should remove my assert because perhaps this is more informative to users?

Let Hans decide.

We should figure out the reason and include it in the documentation.

BTW, nit: see https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#use-correct-grammar (avoid starting sentences with a lower case letter)

The iconSize >= 8 is just a feature (ha) of the gallery demo: https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/material/bottom_navigation_demo.dart#L82

There's no need to constrain the iconSize parameter.

Why is this deprecated?

I'm confused about the relationship between fixedColor, selectedItemColor, and ThemeData.primaryColor. If fixedColor is set, that is selected over selectedItemColor. If fixedColor is unset, than ThemeData.primaryColor is used?

So, fixedColor used to determine the color of the selected items, but only in Fixed BottomNavBars. In the case of Shifting, the selected items were always white.

I'm updating this behavior so that you can customize the selected item color for both Fixed and Shifting bottom nav bars.

My options were:

1. Have fixedColor apply to both Fixed and Shifting bottom nav bars.
2. Rename fixedColor to selectedItemColor <-- breaking change
3. Create a new field called selectedItemColor and "deprecate" fixedColor since the name no longer makes sense.

So, I opted for the 3rd, but for backwards compatibility sake I made it so that if you don't supply selectedItemColor but you do supply a fixedColor, fixedColor will still be used.

Then it's a question of the defaults if neither parameter is provided. Again to keep this backwards compatible, I kept the behavior as is. That means that Shifting nav bars have a default selected item color of Colors.White, and Fixed bottom nav bars have a default selected item color of ThemeData.primaryColor.

I don't think we should just comment on it as being deprecated unless we actually plan to remove it.

cc @Hixie @matthew-carroll @goderbauer

From #27753

It seems like this API is quite working as expected here. Do we take this as an opportunity to clean it up?

Edit: is NOT quite working as expected

I agree with Jonah here. There's a cost to having both colours now: the cognitive overhead of the API being more complicated, but also 8+ bytes per widget to store this field that we don't want people to use.

If you really wanted to keep it and not go through the deprecation process, you could have the constructor argument still exist and just have both it and selectedItemColor set the same field, and have the fixedColor field just return the same value.

But beyond that, we shouldn't say something is deprecated unless it's @deprecated and going to be removed.

Good point, if we do want to deprecate, I should have used @deprecated. I'm fine either way, would people prefer to officially deprecate or leave both fixedColor and selectedItemColor?

I think we should do any deprecations and removals outside of this PR to make it easier to land. I'm not sure what our policy is for the deprecated annotation, but an reasonable process might be:

• Land this PR with fixedColor pointing to selectedColor (and maybe an assert if you assign both).
• A breaking change request asking flutter dev about removing fixed color.
• At some later point in time, removing fixedColor in a separate PR

Sounds good, I will follow the steps that Jonah laid out. Thanks for the input everyone.

[items]s, => [item]s

I think we get carried away with the links sometimes (they make the text a little harder to read). This could just be "items".

The iconSize >= 8 is just a feature (ha) of the gallery demo: https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/material/bottom_navigation_demo.dart#L82

There's no need to constrain the iconSize parameter.