Conversation
Ready for `ControlTheme` class, which is a style without a selector.
The WPF equivalent (`Style`) is in `FrameworkElement` so it would make sense. Will also make stuff a lot easier and removes the need for an `IThemed` interface.
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
Overall, I guess I'm not a fan of introducing another class here. It would have been better for Style to do all of this IMO. |
|
Also, I wonder why there is aversion to using Key like other XAML frameworks? It makes sense to be able to reference a ControlTemplate by Key in both BasedOn and directly in controls to choose which ControlTheme they want to apply overriding anything else. |
It isn't? ControlTheme needs to be stored somewhere, and it usually would be in ResourceDictionaries, and accessed by the key. Same as in WPF, where FrameworkElement.Style is not a key, but an actual style object.
Yeah, but what to do with Selector property? It's confusing to have TargetType and Selector property, where Selector wouldn't work. Also, BasedOn won't work on old styles. |
|
We had two options for naming as well: So, in the end new Any other options possibly? |
If no `Theme` property is provided, try to look up a resource keyed with the control's `StyleKey`.
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
If there are no styles to detach, there's no reason to run a batch update.
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
It's an invalid selector: what does `Button /template/` select?
|
You can test this PR using the following package version. |
Otherwise there's no easy way to apply themes to item containers.
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
Background
The current biggest problem with our styling system is that there is no way to override an existing style without previously applied styles "leaking" through. This is especially important in the context of theming controls: if one has a globally-applied theme, then to re-theme a particular control or set of controls, one must reset every value set in the globally-applied theme. This can be impossible to do if you don't know what the globally-applied theme is and also makes #7679 infeasible as the only way to reset these values is to use local values. This subject has been discussed in various threads:
The two main proposals are contained in #7120 and #7378. This PR implements something more similar to #7120: I will go into the discussion we had over the pros and cons of each of these approaches, and why we chose this solution, in a separate comment.
This PR
This PR implements a system similar to the WPF/UWP styling system, in addition to our existing CSS-like styling system:
Themeproperty was added to theControlclass which accepts an instance of aControlThemeobject. This property is analogous to the WPF/UWPFrameworkElement.Styleproperty.ControlThemeis a type of style that is placed in aResourceDictionaryinstead of aStylescollection, and has aTargetTypeproperty instead of aSelector. This class is analogous to the WPF/UWPStyleclass.BasedOnpropertyControl.Themeis not set, then the framework will attempt to find aControlThemeresource with a key matching the control's style keyControl.Themecan be specified inline, e.g.Control.Themecan be set via aStaticResource, e.g.ControlThemecan contain nested styles which are permitted to select on the control that has the theme and its direct templated childrenNaming
This system unfortunately diverges from WPF/UWP's naming:
FrameworkElement.Styleproperty becomesControl.ThemeStyleclass becomesControlThemeIdeally we would have used the same naming as WPF/UWP, but the problem is that we already have a
Styleclass, and it has aSelector. ASelectoris not valid on aControlTheme, and similarlyControlThemehasTargetTypeandBasedOnproperties which are not valid on styles.Our choices here were:
Styleclass. This would be a huge API breakage.Styleclass withSelector,TargetTypeandBasedOnproperties, and choose which ones are relevant depending on where theStyleappears (in aStylescollection or a resource dictionary). This would be confusing.Todo
BasedOnFor subsequent PRs: