[nicolaihenriksen]

This PR builds on top of the "RFC" around the TextBox style change: #3461

(Visual) Breaking changes !!!

This PR includes breaking changes.

• Applying wpf:HintAssist.IsFloating="True" is no longer enough to change from the default style to the floating hint style. Explicit opt-in in the form of Style="{StaticResource MaterialDesignFloatingHintTextBox}" is now required.
  • Although this is a breaking API change, I believe it is a good change. It allows better control to override properties because they are now set in the style rather than in a trigger inside the ControlTemplate.Triggers collection.
• Minor changes to the TextBox control height in the various styles are to be expected; this also affects some of the UI tests which have been temporarily modified to run green. When all styles adopt the new SmartHint approach, they should be able to run "normally" again.

General idea

Instead of a SmartHint consumer relying on a lot of "magic numbers" to place the floating hint correctly, this PR attempts to let the SmartHint handle the placement of the floating hint itself, with a few supporting properties.

In the layout above, the green box represents the PART_ContentHost of the TextBox style which holds the user input. The red box represents the SmartHint as a whole; this element spans the width of the prefix-text, the user input, and the suffix-text in the layout to be able to place float the hint to either align with prefix/suffix, or with the user input. The blue/purple box represents the "scaled hint" inside of the SmartHint.

From a SmartHint consumers point-of-view (e.g. the TextBox style), the idea is that you provide a SmartHint.FloatingTarget, which similarly to the Popup.PlacementTarget is a dependency property where the caller provides a target element which the hint will then (vertically) float on top of. In the example above, the SmartHint.FloatingTarget is set to PART_ContentHost to always float the hint directly on top of the user input. There are a few other supporting properties to enable the hint to horizontally align with either the user input or the prefix/suffix texts; depending on the value of HorizontalContentAlignment as well.

Examples

Align with prefix	Align with user input

In the - slowed down - animations above, you should note that the whole SmartHint (red box) floats upwards, but only far enough such that the "scaled down hint" (blue/purple box) rests directly on top of the SmartHint.FloatingTarget. Effectively overlapping the user input with the "empty space" left after scaling the hint down. In the outlined style, the SmartHint.FloatingTarget is set as the outer Border, and a few supporting properties have been set to allow the hint to center align (vertically) with the border line.

This approach, in my opinion, works better than the old implementation. The intention is to retain all existing functionality (but improve upon it), and also add support for change of font size and multi-line input. I believe the branch in its current state nearly has that, with just a few minor things I need to look into / clean up.

The intention is to use the TextBox style as the guinea pig for adopting the new approach, and then to roll it out to all the other styles containing a SmartHint afterwards. Backwards compatibility is intended to be maintained, so if a non-default value for HintAssist.FloatingOffset is supplied, that will still be respected. It could however be considered a both a behavioral breaking change (alignment with prefix/suffix/user-input) and a (slight) visual breaking change.

Funkyness

This particular (existing) feature is rather funky. I retained back-compat of it, but it is not aligned across the styles at all. It seems like a shortcut instead of doing an actual MD3 version of the styles. It basically changes the default TextBox style so that the underline behaves slightly different on hover.

Any comments/feedback/pushback is welcome.