Control themes

[kekekeks]

The current styling system isn't really suitable for defining controls themes:

• we don't have a way to properly specify the default theme
• we don't have a way to completely re-style a control and prevent the current theme selectors from leaking to such re-styled control

So we need a switchable group of styles that can be associated with a control like Style is associated with one in WPF and basically act like WPF's style.

<Button>
    <Button.ControlTheme>
        <ControlTheme BasedOn="{x:StaticResource SomeBaseButtonTheme}">
             <Setter Property="Background" "Value"="Red"/>
             <Style Selector=":pointerover">
               <Setter Property="Background" "Value"="Green"/>
             </Style>
        </ControlTheme>
    </Button.ControlTheme>

</Button>

Such control theme could be switched and manipulated by selectors in our regular CSS-like styles.

A control would announce its default theme by implementing

interface IHaveDefaultControlTheme
{
       Style GetDefaultControlTheme();
}

which would be generated by the XAML compiler based on x:DefaultControlThemeFor in a XAML file in the same assembly:

<ControlTheme x:DefaultControlThemeFor="{x:Type MyControl}">

</ControlTheme>

[robloo]

I don't see this functionality on the roadmap and I know you are working to finish up 0.9 at the moment. Can it be assumed this would be targeted for 1.0? As you mentioned in #2981 it would speed up porting of controls which would then open up the floodgate of fixes and new controls coming over from WPF.

[handicraftsman]

Would be nice if used with something like reacts contexts - resource dictionaries are not sufficient because they cannot override parent values iiuc.

[danwalmsley]

Some High level requirements:

• Display Modes
  iOS, Windows 10, OSX operating systems Request Light, Dark and HighContrast modes from the application...

Any theme should be able to express:

Default colours (probably Light)
Dark, and HighContrast

If a theme only expresses 1, (it has to be the default) and thats what avalonia falls back to say when HighContrast is asked for.

• Overriding Display Mode
  Any Control / Layoutable should be able to say:

Im rendered with Default theme, instead of HighContrast...

This is common for parts of apps that express branding, logos, media, etc

or something way of expressing the same thing.

In UWP they have RequestedTheme property and its an enum with Light / Dark... it seems like UWP is limited to just 2 themes at first... however that is not the case.

because the OS has the concept of Light and Dark that enum expresses that.

A MacOSX theme for UWP is possible, but the theme itself should optionaly define the Default, Dark and High contrast themes

[robloo]

This is an API breaking change as I understand it and in #2239 (comment) it's mentioned 0.11 is going to lock down breaking changes considerably. What happens to this if it doesn't make 0.11? Will it never get implemented?

This is a fundamentally important feature as I see it to the styling system. The current CSS like system is quite powerful but this issue needs to get closed to finish it. (Triggers would be nice too but I suppose behaviors exist for that)

Without this change themes and control styles are more complex than they need to be. We need to wrap each controls default style and template into a single parent container "Style".

[danwalmsley]

@robloo this will get implemented, breaking changes will cause the major revision number to increase by 1.

btw... 0.11 will never be released... the next major version will be 11.0.0

[grokys]

Work was started on this a while ago on https://github.com/AvaloniaUI/Avalonia/commits/feature/2769-control-themes - just needs to be finished off.

[sgf]

In the design of Style, the design of XAML is very bad. It is highly redundant and difficult to read.

I suggest adding support for CSS-3 directly. Use various advanced improvements made to CSS styles in the web(sass,less,scss...) .

[robloo]

I suggest adding support for CSS-3 directly. Use various advanced improvements made to CSS styles in the web(sass,less,scss...) .

GTK eventually went that route too. However, I think you should create a new issue for that.

WPF styling with triggers was pretty intuitive and easy to read. UWP muddied things up a bit for beginners with the VisualStateManager (It also meant hardcoded string states in code-behind which I don't prefer). I'm not a huge fan of pseudoclasses here in Avalonia either but they are more powerful than just triggers on standard properties and work similar in my mind to UWPs VisualStates.

Regardless, XAML styling is fairly straightforward once you get used to it and is far more powerful in Avalonia. The only issue is there is no container for them and you end up with lots of fragments for one control's default style. That is what I hope this issue fixes.

[sgf]

I suggest adding support for CSS-3 directly. Use various advanced improvements made to CSS styles in the web(sass,less,scss...) .

GTK eventually went that route too. However, I think you should create a new issue for that.

Someone has already raised it, and I have already expressed support in this issue.
#3686

As for which one is better,
the shorter the better,
the smaller the number of typing characters, the better,
and the smaller space in view of the same function, the better.

<Style Selector="TabControl">
    <Setter Property="Background" Value="#F0F0F0"/>
    <Setter Property="Height" Value="120"/>
</Style>

TabControl{
Background:#F0F0F0;
Height:120;
}

[maxkatz6]

@sgf I would suggest to keep css-related discussion in #3686 issue. CSS doesn't even tries to solve problem of this ticket.

[maxkatz6]

Stepping back, why we need it at all, is to simplify control restyling.
Easy to imagine situation, where developer included some custom/default theme, which defined many properties and states (pointerover, pressed...) for simple button. But then developer wants to create new independed button style, which will have very special styling. Developer will need to revert all of these styles related to simple button in order to have exactly what they need.

Basically CSS has exactly the same problem for default controls. They have "scoped css" (as we do have scoped styles), but you can't replace these styles with another, without defining new ones on top of old ones (or technically you can remove style include, but...).

[robloo]

I won't argue which one is better. Each has preferences for certain reasons. I will say XAML isn't difficult. This issue is for something different than a full CSS/JSON styling system though.

[maxkatz6]

Why it's not trivial to implement right now.
In proposal XAML compiler should wire default theme with controls in the same assembly. But in reality, we don't have (and we shouldn't have) one default theme. User should be able to completely drop old or fluent theme and apply their own. So, control shouldn't know about any specific theme but expect one to be applied. So "IHaveDefaultControlTheme" interface isn't practical.

I see following design as a solution:

Define "default" theme for button:
FluentButton.axaml

<ResourceDictionary>
   <ControlTheme Type="Button" x:Key="FluentButtonStyle">
       <Style Selector="Button">
           <Setter Property="Template" Value=" ... " />
       </Style>
       <Style Selector="Button:pointerover">
           <!-- -->
       </Style>
   </ControlTheme>
</ResourceDictionary>

Apply default theme globally:
FluentThemeDefinitions.axaml

<Styles>
   <Style Selector="Button">
      <Setter Property="ControlTheme" Value="{StaticResource FluentButtonStyle}" />
   </Style>
</Styles>

Develop will be able to completly ignore default theme and implement their own in the same way, OR they can base on it:
MySuperTheme.axaml

<Styles>
   <Style Selector="Button">
      <Setter Property="ControlTheme">
        <ControlTheme Type="Button" BasedOn="{StaticResource FluentButtonStyle}">
          <Setter Property="Height" Value="66" />
        </ControlTheme>
     </Setter>
   </Style>

   <!-- Or create a new one which will not be based on any other theme -->
   <Style Selector="Button.special-button">
      <Setter Property="ControlTheme">
        <ControlTheme Type="Button">
          <Setter Property="Height" Value="22" />
        </ControlTheme>
     </Setter>
   </Style>

   <!-- And old global styles will work too -->
   <Style Selector="Button">
       <!-- Will be applied to every button  -->
   </Style>
</Styles>

Questions/problems:

1. We probably have to allow any selector inside of ControlTheme, even unrelated to Button, but potentially related to its content. Can we scope it in this way?
2. ControlTheme=null must be allowed: avoid breaking changes (there are developers without fluent/default theme) and allow old way styling existed before
3. Setting ControlTheme inside of a style essentially modifies application styles while they are executing, which possibly can cause undefined behavior (set control theme inside of another control theme which will set it again to the first theme...hello stack overflow).

[workgroupengineering]

Executing code needs to find generic.xaml in each referenced assembly using reflection (with or without attribute hint).
But to be honest even simple StyleInclude in Avalonia isn't AOT friendly, because it also uses reflection right now. While StyleInclude can be fixed with compiler update, it's hard to imagine how to make generic.xaml work without any kind of reflection.

At the level of XamlIL one could intercept resources named generic.(xaml | axaml) and transform it into a class with a specific interface (IHaveDefaultControlTheme, ecc...).

You could also intercept a pattern like generic.[Gtk | macOs | iOs | Windows10 | Windows11].(xaml | axaml) and load predefined styles for the platform.

[robloo]

I agree with @workgroupengineering. Additionally, since you parse XAML ahead of time and compile it, why is reflection even needed? I'm not sure I understand the limitations here but in my mind you have all the pieces already to avoid a new default style interface and code. Of course @kekekeks is smarter than me so I need to be careful with what I say, lol

[maxkatz6]

Xaml is parsed and compiled, that's true. Just like you can have C# class compiled.
But imagine instead of creating new instance of that C# type by calling its ctor you decide to use reflection and create instance by type string name. That's why AOT can trim this type out without knowing it was actually used.

[maxkatz6]

Saying that, why can't we inject all of these compiled generic.xaml into Application.Styles with some compiler magic. All of dependencies should be known at this time.

[robloo]

If reflection is absolutely required, you can also annotate the compiled code to ensure it is trimmed and managed in AOT scenarios correctly. I have only needed to do this a few times with UWP but expect it isn't difficult in NativeAOT which evolved from that basis.

[workgroupengineering]

I think something like this is more readable and less verbose:

<Styles>
   <Style Selector="Button" BasedOn="{StaticResource FluentButtonStyle}">
         <Setter Property="Height" Value="66" />
   </Style>

   <!-- Or create a new one which will not be based on any other theme -->
   <Style Selector="Button.special-button" BasedOn="{StaticResource FluentButtonStyle}">
          <Setter Property="Height" Value="22" />
   </Style>

   <!-- And old style global styles will work too -->
   <Style Selector="Button">
       <!-- Will be applied to every button  -->
   </Style>
</Styles>

[workgroupengineering]

It's less verbose, but won't work very well. How we can tell that your second style shouldn't be applied together with the first one. I.e. just like if you will remove BasedOn. It's not obvious that existence BasedOn property will completely change how styles are composed together (i.e. ignore every other style but one which it is BasedOn)

   <Style Selector="Button.special-button" BasedOn="{x:Null}">
          <Setter Property="Height" Value="22" />
   </Style>

   <Style Selector="Button.special-button" BasedOn="{x:Empty}">
          <Setter Property="Height" Value="22" />
   </Style>

[maxkatz6]

Still, while I agree it's less verbose, it's also less intuitive as for me. Maybe somebody else has opinion on it too.

[sgf]

I think something like this is more readable and less verbose:

<Styles>
   <Style Selector="Button" BasedOn="{StaticResource FluentButtonStyle}">
         <Setter Property="Height" Value="66" />
   </Style>

   <!-- Or create a new one which will not be based on any other theme -->
   <Style Selector="Button.special-button" BasedOn="{StaticResource FluentButtonStyle}">
          <Setter Property="Height" Value="22" />
   </Style>

   <!-- And old style global styles will work too -->
   <Style Selector="Button">
       <!-- Will be applied to every button  -->
   </Style>
</Styles>

<Style>
 Button{
 }
 
 Button: .FluentButtonStyle{
 Height:66;
 }
 
 Button.special-button: .FluentButtonStyle{
 Height:22;
 }
</Style>

[maxkatz6]

@sgf your code works in avalonia with xaml syntax and doesn't solve the problem

[sgf]

@sgf your code works in avalonia with xaml syntax and doesn't solve the problem

Im sorry,You are right, my reply is off the subject.

[robloo]

After thinking about this a while, I think adding a new Button.ControlTheme property is a bad idea. It all should be swapped-out in the styles themselves. Selectors somehow should be expanded to be aware of the theme they apply to. We need to move closer to what WPF/UWP do in this area which is far more intuitive.

we don't have a way to completely re-style a control and prevent the current theme selectors from leaking to such re-styled control

Honestly, we should probably have named themes similar to pseudo-classes and then have an additional theme selector evaluated for each style. The styles themselves can decide which theme they apply to.

[robloo]

Although this wouldn't work with the fluent theme optimizations which are now just swapping out base resources dynamically as they should be. That thinking is correct and we really should be managing theme-related base colors/brushes separately and then swapping them out all together: leave the control default styles and templates alone. It might be a good idea to take the strategy from UWP and make separate ResourceDictionary instances for each theme and swap them out. ResourceDictionary could probably have a selector itself.

Edit: Some of this could be added on to this idea: #5027 (comment)

[kekekeks]

We need to move closer to what WPF/UWP do in this area which is far more intuitive.

Well, "control theme" essentially is "WPF/UWP Style with ability to apply nested selectors", we just have the word "style" already used and didn't come up with any better term. It's not about application-wide themes, it's about scoping selectors into groups and switching between those just like WPF/UWP do.

[robloo]

Ah, OK, the name is what confused me a bit. However, I would also not use a separate collection for this. I think everything can be done with styles and dynamic resources to handle the real theme (light, dark) changes. I'll add some further ideas in #5027 which accidentally is converging with this. However, I think I have a solution for nearly everything :) Style grouping in a hierarchy is the fundamental idea.

Also, in terms of naming and control themes, we are really talking about two different things – historically the terminology is the same:

1. Full control themes like Aero or Fluent
2. Variants of a control themes like light or dark
   UWP introduced adds the ThemeResource (a subset of DynamicResource) to handle case 2 specifically. Avalonia has already solved this case in some recent commits.

[rabbitism]

Hi, I want to understand the limitation of
"ControlTheme style may not directly contains child or descendent"
Why does this rule exist?
It's really tough to design a "container" theme.