11.0.0 Preview 5

[danwalmsley]

release/11.0.0-preview4...release/11.0.0-preview5

---

This discussion was created from the release 11.0.0 Preview 5.

[rabbitism]

Do we have documentation of how to use FluentTheme in preview5?

[ArchLeaders]

Been looking through this for a while now, but I haven't been able to get anything to work.
I tried moving the resources (as stated above) into a theme resource, which worked for the statically-defined colors, but the last 5 which use DynamicResource still always use Default like before.

<ResourceDictionary xmlns="https://github.com/avaloniaui"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:sys="clr-namespace:System;assembly=netstandard">
    <ResourceDictionary.ThemeDictionaries>
        <ResourceDictionary x:Key="Default">
            <SolidColorBrush x:Key="DockApplicationAccentBrushLow">#FF0000</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentBrushMed">#FF0000</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentBrushHigh">#FF0000</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentForegroundBrush">#FF0000</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentBrushIndicator">#FF0000</SolidColorBrush>

            <SolidColorBrush x:Key="DockThemeBorderLowBrush" Color="{DynamicResource SystemBaseMediumLowColor}" />
            <SolidColorBrush x:Key="DockThemeBackgroundBrush" Color="{DynamicResource RegionColor}" />
            <SolidColorBrush x:Key="DockThemeAccentBrush" Color="{DynamicResource SystemAccentColor}" />
            <SolidColorBrush x:Key="DockThemeForegroundBrush" Color="{DynamicResource SystemBaseHighColor}" />
            <SolidColorBrush x:Key="DockThemeControlBackgroundBrush" Color="{DynamicResource SystemAltHighColor}" />
            <sys:Double x:Key="DockFontSizeNormal">12</sys:Double>
        </ResourceDictionary>
        <ResourceDictionary x:Key="Dark">
            <SolidColorBrush x:Key="DockApplicationAccentBrushLow">#007ACC</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentBrushMed">#1C97EA</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentBrushHigh">#52B0EF</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentForegroundBrush">#F0F0F0</SolidColorBrush>
            <SolidColorBrush x:Key="DockApplicationAccentBrushIndicator">#007ACC</SolidColorBrush>

            <SolidColorBrush x:Key="DockThemeBorderLowBrush" Color="{DynamicResource SystemBaseMediumLowColor}" />
            <SolidColorBrush x:Key="DockThemeBackgroundBrush" Color="{DynamicResource RegionColor}" />
            <SolidColorBrush x:Key="DockThemeAccentBrush" Color="{DynamicResource SystemAccentColor}" />
            <SolidColorBrush x:Key="DockThemeForegroundBrush" Color="{DynamicResource SystemBaseHighColor}" />
            <SolidColorBrush x:Key="DockThemeControlBackgroundBrush" Color="{DynamicResource SystemAltHighColor}" />
            <sys:Double x:Key="DockFontSizeNormal">12</sys:Double>
        </ResourceDictionary>
    </ResourceDictionary.ThemeDictionaries>
</ResourceDictionary>

I also can confirm that changing the last three resources to static values (like the first five) and it worked as expected. So the issue seems to be in DynamicResource.

Anything obvious I missed in that PR? Didn't read the comments too carefully, but I roughly looked through the whole thread for keywords and nothing stuck out.

[Sigrec]

I'm having this same issue a lot of nested Properties broke looks like mainly because in the Fluent theme they got changed from a Template Binding to DynamicResource. When I change the binding to Binding instead of CompiledBinding it flickers constantly, and this is the case on my other windows besides my MainWindow unsure why.

[jgcodes2020]

Sorry: I mean the mode. Dark or Light

<Application xmlns="https://github.com/avaloniaui"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             x:Class="AvaloniaAppTemplate.App"
             RequestedThemeVariant="Default">
             <!-- "Default" ThemeVariant follows system theme variant. "Dark" or "Light" are other available options. -->

    <Application.Styles>
        <FluentTheme />
    </Application.Styles>
</Application>

This doesn't work for me: setting the Application to Dark theme leaves everything in Light theme

[timunie]

@jgcodes2020 please try preview6.

[jgcodes2020]

@jgcodes2020 please try preview6.

nevermind, it's not an issue on your end

[chenjing1294]

Great work!

[culushishui]

When is release?

[timunie]

Preview 5, yesterday. Stable probably soon, if not much bugs are in preview 5. The plan is to have a RC with next release.

[robloo]

Really like all the work put into the preview 5 release along with the new features. I do want to caution against releasing the RC too soon though. Preview 5 has more issues than any of the previous previews and I'm seeing quite a few more-fundamental problems with controls just not rendering correctly along with various crashes. This is going to get fixed, it's just going to take a bit to narrow down the issues and close them. We don't want to repeat the Maui release problems, there are already many breaking changes that will cause some push back.

[llfab]

I agree. I love the work, I respect the braveness regarding API breaks. Only the issues that we found in our simple apps indicate that the latest changes have introduced bugs in untested paths of code. We better take the time to do it (more) right. Nobody expects 11.0.0 to be free of bugs but hopefully not on the current level.

[grokys]

Agreed, we need to get all the problems ironed out before then final release. Please feel free to link issues here for more visibility.

[llfab]

Some issues collected here:

• Text rendering differs slightly in size between preview4 and preview5 #10268
• ListBoxItem.IsSelected Binding does not work anymore with preview5 #10249
• DoubleTransition animated until the end and then snaps back to original value in preview5 #10255

[robloo]

Light/Dark theme variant also isn't applying correctly in a few cases. This is causing problems with displaying controls -- even when not toggling the variant.

I don't think the issue is fully understood yet (was seeing it occurring when IsVisible was changing) however the two open issues I'm aware of are:

• ThemeVariantScope doesn't refresh resources on first change of RequestedThemeVariant #10201
• Theme Variant Won't Apply to Popup #10292

[amwx]

I think the DynamicResource fix PR was merged the other day, but I still need to check it fixes using alternate theme variants (will report back when I've tested that)

My biggest issue right now is #10203, it seems the composition renderer doesn't go into idle in the previewer process, which makes the previewer constantly send FrameMessages and consumes various amounts of CPU, which is causing some other issues in VS (I can also repro the no idle with Rider)

[Sputnik24]

Question regarding ThemeVariant:
I don't get the meaning of Default but find something out which I find suprising as it is not documented:

When I set RequestedThemeVariant="Default", it uses the Systems theme variant, light or dark, and even better: When I change the Systems theme, the running application changes it's theme, as well. Tested with Windows 10 21H2 and Ubuntu 22.10 and Gnome.

This is awesome! But I understood Default wrong and would expect it to be System or SystemDefault. I also looked at other code sources, e.g. ChatGPT from @wieslawsoltes and if I understand his code correctly (https://github.com/wieslawsoltes/ChatGPT/blob/main/ChatGPT.UI/Themes/Themes.axaml) Default is used as Light.

Did I miss something?

[maxkatz6]

When I set RequestedThemeVariant="Default", it uses the Systems theme variant, light or dark, and even better

Not exactly. It uses theme variant of parent. If you set it on Application, then system variant is used (no other parent). If you set in on Window - Application variant is used. If you set it on theme scope - Window variant is used... So, it's not necessary a system one. And by default, value is inherited from parent, which matches the name - Default.

Personally, I do think Default in the resource dictionaries is a little strange.

But I agree that this part feels a bit unclear.
Same keyword "Default" is used, but in different context. It's more like a default value which is used, when resource wasn't found in other dictionaries. In other words - fallback dictionary. UWP has the same keyword used in the same context, but its default resources built in a way replacing "Dark" instead of "Light" as in Avalonia.

We can add two different keywords for these two different contexts (Default and Fallback, for example), but then we would need to add runtime validation to disallow mixing usage (there is no sense in using Fallback on requested theme, for example) or making special case in compiler to validate there. Either way I would want to avoid special cases.

If to do anything, I would rather remove "Default" key handling from theme dictionaries and throw in runtime if it was passed by mistake. Even though "fallback dictionary" functionality will be missed from there, we still have ThemeVariant.InheritVariant.

[robloo]

I think it's more clear to require explicit light or dark keys instead of default in theme resource dictionaries. I suppose there might be a case where you want to share the same value, for example, between light and highcontrast though and in that case having default would be useful. Probably we should allow it but be more disciplined and only use it for shared resources. Otherwise just write Light for the key.

[timunie]

I wonder if another name like System or Inherit would be clearer then Default. Default could be a static Property which can be set to whatever theme the develooer wants to be the default theme.

[robloo]

@timunie For the original case (not in theme dictionaries) inherit makes sense. That's what it is actually doing.

For theme dictionaries default is a better name as its more accurate. However, I wasn't thinking this through. You can just define a normal resource outside of a theme dictionary and that is shared when you need it. I think it can still be overwritten by a theme dictionary too. So there is no point in keeping Default key support and I agree it should be removed. @maxkatz6

[maxkatz6]

You can just define a normal resource outside of a theme dictionary and that is shared when you need it

Yes and no. There is a difference.
Same as in UWP, resource defined outside of theme dictionaries will have a higher priority. So, it's not a "default" or "fallback" anymore. It's just a one to choose.

[malstraem]

Any chances to see full syntax highlighting and autocomplete in Visual Studio the same as in Rider?

[malstraem]

@amwx,

re syntax highlighting: I'm assuming you mean something more like what WPF/UWP designers offer over the default XML syntax highlighting we have now?

Yes, even though Avalonia looks amazing and has a lot of great XAML changes comparing to WPF and WinUI 3 - the basic XML highlighting in Visual Stduio is a real showstopper for my team searching cross-platform framework.

If so, we have to use the XML language service right now as if we try to use XAML, it loads the WPF/UWP text taggers that flag everything Avalonia as an error since it only registers the Microsoft Xaml schema.

Do I understand correctly that XAML dialect highlighting in Microsoft UI frameworks is implemented at the IDE level and AXAML highlighting in Rider is also implemented by JetBrains themselves? And there is no mechanism similar to LSP?

[Mrxx99]

@malstraem,

Yes, even though Avalonia looks amazing and has a lot of great XAML changes comparing to WPF and WinUI 3 - the basic XML highlighting in Visual Stduio is a real showstopper for my team searching cross-platform framework.

Have you looked at Rider or using Resharper in Visual Studio for your team? Resharper also greatly improves the syntay highlighting and completion for AXAML files.

[amwx]

Do I understand correctly that XAML dialect highlighting in Microsoft UI frameworks is implemented at the IDE level and AXAML highlighting in Rider is also implemented by JetBrains themselves? And there is no mechanism similar to LSP?

Pretty much. The Xaml language service is hardcoded to WPF/UWP - it's also why Avalonia xaml files are .axaml instead of .xaml as VS kept opening them with the WPF designer. Whether there's a way to update that to allow other schemas, I don't know. As I said, I know we can add a custom textmate grammar file to the extension, but that would be hard to get right and match with VS's expectations. VS did add LSP support (I stumbled on this yesterday after reading your comment), but like everything else is severely under-documented so its hard to figure out how to properly implement it.

[malstraem]

@amwx, i think NoesisGUI Language Server for VS Code can be very usefull for understand process. Maybe its need to open discussion (or issue?) in AvaloniaVS repo? I don't have much free time, but I will try to research this too. Visual Studio is the main instrument in the .NET world and no syntax highlight is disappointment, this issue must be solved.

[llfab]

I would like to add some "food for thought". Yes, anything that is available in other tools which is not in VS is not so great. Remember, Rider is not an option for everyone because it supports only .NET projects. In some cases developers have mixed projects with both C# and C++ which I believe would not work in Rider...

I do come from VS and WPF and I observed these differences:

• In WPF designer you can select the visual element and the selection would be reflected in the XAML code editor. So for many aspects editor and designer go hand in hand
• Better syntax highlighting for WPF

However:

• Even for WPF I ended up using only the code editor because the designer does not help even for user controls with low complexity. The designer then just worked as the previewer and allowed for quick turnaround
• After getting used to the Avalonia designer/previewer I found myself more efficient than in WPF because the previewer would also allow for complex interaction (hover, mouse click, ...) and for previewing the user control not only once but in many instances e.g. for different settings/modes which further decreased turnaround times

Concluding:

• I'm not saying syntax highlighting is not important but I would be careful not to overrate this
• I find this especially important compared to other aspects like the (IMHO) superior previewer principle
• (I (personally) would rather put effort into a more efficient and more robust previewer then in syntax highlighting )