Feature Request: Add ComboBoxAssist.DropDownBackground to allow customizing the dropdown background color

[racpast]

Is your feature request related to a problem? Please describe.
Currently, customizing the background color of a ComboBox's dropdown popup is very cumbersome. There are two main problems:

• Complexity: There is no simple property to set the dropdown's background color. A developer must resort to creating a completely custom ControlTemplate to change this, which is an extremely verbose and difficult process for what should be a simple customization.
• Transparency Issues: The default ControlTemplate is not designed to handle semi-transparent backgrounds correctly. The ScrollViewer inside PART_Popup has its Background bound to the PART_Popup's Background. When a semi-transparent brush is used, this results in the color being applied twice (color stacking), leading to a final color that is darker and less transparent than intended.

Describe the solution you'd like
I would like to propose adding a new attached property to the ComboBoxAssist helper class:

public static readonly DependencyProperty DropDownBackgroundProperty;

This property, of type Brush, would allow developers to directly and easily set the background of the ComboBox dropdown in XAML.

Describe alternatives you've considered
The only viable alternative currently is to extract and copy the entire default ControlTemplate of the ComboBox from the library's source code and manually modify its internal elements. This approach is not practical for a simple color change as it is very brittle and makes it difficult to receive updates for the control in the future.

Additional context
Through investigation, implementing this feature correctly requires addressing a few key challenges in the existing ControlTemplates:

• Trigger Precedence: The ControlTemplate.Triggers for wpf:ColorZoneAssist.Mode in MaterialDesignFloatingHintComboBoxTemplate will override the popup background. The implementation must integrate the new DropDownBackground property into these triggers, likely using the existing FallbackBrushConverter to give DropDownBackground the highest priority.
• Color Stacking Fix: To solve the transparency issue, the Background property of the ScrollViewer inside PART_Popup should be hardcoded to Transparent.
• Multiple Templates: The Material Design in XAML library uses different ControlTemplates for different ComboBox styles. For this feature to be consistent, the changes must be applied not only to the main MaterialDesignFloatingHintComboBoxTemplate but also to the templates used by MaterialDesignDataGridComboBox.

[nicolaihenriksen]

@racpast Thank you for the thorough description! A few thoughts/comments (mainly left here for someone to consider when/if creating a PR to resolve the issue):

• I agree that setting the background with the current API is cumbersome! However, I believe the intention with the "theme-refactor" in v.5.0.0, was to avoid exposing attached/dependency-properties for brushes/colors, but rather make more dedicated brushes that can be overridden from calling code. In this case, the MaterialDesign.Brush.Background base background color is used in the template. I would suggest creating an alias (or perhaps a dedicated entry) for that in ThemeColors.json named something like MaterialDesign.Brush.ComboBox.Popup.Background (likely other brushes/colors are needed as well).
• I agree with your point about setting Background=Transparent (or omitting it) in the ScrollViewer inside PART_Popup to avoid the color-stacking when using non-opaque colors/brushes, however:
  • The current template uses the RemoveAlphaBrushConverter to actually remove any alpha-channels applied on the background brush, so currently semi-transparency is not allowed. I assume this was an intentional design decision. Not entirely sure why though. Perhaps it is relevant for the ColorZoneAssist.Mode != Standard/Inverted scenarios, but that is just a guess. We could consider removing the use of the converter if it doesn't serve an actual purpose; I don't know if it does or not!
• Regarding trigger-precedence: As per my first bullet, I think we need to ensure all of the "special" brushes applied in these triggers, are exposed with distinct (ComboBox-specific) resource keys which allows calling code to manipulate them. The resource keys used for ColorZoneAssist.Mode=Light/Dark are already in place, but the ones for PrimaryLight, PrimaryMid, PrimaryDark, SecondaryLight, SecondaryMid, SecondaryDark are currently not ComboBox-specific, and we should expose a dedicated brush for each of these. Doing so will eliminate the need for a PriorityBinding/FallbackBrushConverter in my opinion.
• Regarding multiple templates: AFAIK all the templates rely on the base template which is responsible for applying the color/brush in question, so I think this will come "automagically" for all the different styles.

A sample snippet of what such a brush override could look like at the call-site:

<ComboBox materialDesign:HintAssist.Hint="OS">
 <ComboBox.Resources>
   <SolidColorBrush x:Key="MaterialDesign.Brush.ComboBox.Popup.Background" Color="#CCFF0000" />
 </ComboBox.Resources>
 <ComboBoxItem Content="Android" />
 <ComboBoxItem Content="iOS" />
 <ComboBoxItem Content="Linux" />
</ComboBox

The intention in the snippet is to set the background of the ComboBox popup to a semi-transparent red color. Resulting in something like this:

[racpast]

@racpast Thank you for the thorough description! A few thoughts/comments (mainly left here for someone to consider when/if creating a PR to resolve the issue):

• I agree that setting the background with the current API is cumbersome! However, I believe the intention with the "theme-refactor" in v.5.0.0, was to avoid exposing attached/dependency-properties for brushes/colors, but rather make more dedicated brushes that can be overridden from calling code. In this case, the MaterialDesign.Brush.Background base background color is used in the template. I would suggest creating an alias (or perhaps a dedicated entry) for that in ThemeColors.json named something like MaterialDesign.Brush.ComboBox.Popup.Background (likely other brushes/colors are needed as well).

• I agree with your point about setting Background=Transparent (or omitting it) in the ScrollViewer´ inside PART_Popup` to avoid the color-stacking when using non-opaque colors/brushes, however:

  • The current template uses the RemoveAlphaBrushConverter to actually remove any alpha-channels applied on the background brush, so currently semi-transparency is not allowed. I assume this was an intentional design decision. Not entirely sure why though. Perhaps it is relevant for the ColorZoneAssist.Mode != Standard/Inverted scenarios, but that is just a guess. We could consider removing the use of the converter if it doesn't serve an actual purpose; I don't know if it does or not!

• Regarding trigger-precedence: As per my first bullet, I think we need to ensure all of the "special" brushes applied in these triggers, are exposed with distinct (ComboBox-specific) resource keys which allows calling code to manipulate them. The resource keys used for ColorZoneAssist.Mode=Light/Dark are already in place, but the ones for PrimaryLight, PrimaryMid, PrimaryDark, SecondaryLight, SecondaryMid, SecondaryDark are currently not ComboBox-specific, and we should expose a dedicated brush for each of these. Doing so will eliminate the need for a PriorityBinding/FallbackBrushConverter in my opinion.

• Regarding multiple templates: AFAIK all the templates rely on the base template which is responsible for applying the color/brush in question, so I think this will come "automagically" for all the different styles.

A sample snippet of what such a brush override could look like at the call-site:

@nicolaihenriksen Thanks for the detailed explanation!
Using dedicated theme brush keys like MaterialDesign.Brush.ComboBox.Popup.Background sounds like a good and clean approach. That would indeed make it much easier to customize the popup background without relying on attached properties or full template overrides.
Also, I agree that removing or re-evaluating the RemoveAlphaBrushConverter could make transparency support more intuitive and predictable.
Thanks again for the insights and suggestions!