Es gibt eine lange Liste von UI-Frameworks für C# und .NET – allein Microsoft hat mit Windows Forms, WPF, WinUI, .NET MAUI und ASP.NET Core Blazor ein vielseitiges Angebot im Programm. Wenn wir eine Applikation für Windows entwickeln wollen, haben wir also die Qual der Wahl. Unter macOS wird die Liste bereits kleiner, mit .NET MAUI und ASP.NET Core Blazor stehen davon nur noch zwei Frameworks zur Auswahl. Möchte man für Linux entwickeln, so fällt schließlich auch .NET MAUI raus und wir haben nur noch ASP.NET Core Blazor übrig. Hier kann allerdings noch etwas fehlen, da es einen Browser benötigt, innerhalb dessen der HTML-Content gerendert werden kann. ASP.NET Core Blazor Hybrid als Container ist hierfür eine gängige Variante, unter Linux kann sie aber nicht verwendet werden. Wir müssten uns dort selbst um einen Container für die ASP.NET-Core-Blazor-Applikation kümmern oder ein entsprechendes Open-Source-Projekt suchen.
ZUM NEWSLETTER
Regelmäßig News zur Konferenz und der .NET-Community
In diesem Artikel beschäftigen wir uns mit einer völlig anderen Variante: Avalonia, ein Open-Source-UI-Framework. Es basiert auf .NET und steht für alle genannten Plattformen zur Verfügung. Darüber hinaus unterstützt es auch mobile Geräte (Android, iOS) und sogar den Browser. Avalonia ist nicht von Microsoft, sondern ein communitygetriebenes, unabhängiges Projekt, das bereits vor über einem Jahrzehnt entstand. Im Jahr 2023 hat das Team hinter Avalonia UI bereits das 10-jährige Jubiläum gefeiert.
Um Avalonia zu verstehen und einschätzen zu können, muss man sich damit beschäftigen, wo das Framework seine Wurzeln hat. Es ist als Cross-Platform-UI-Framework für den Desktop mit Unterstützung für Windows, macOS und Linux gestartet. Es hat viele Ideen und Konzepte von WPF übernommen – WPF war zu dieser Zeit noch der De-facto-Standard für UI-Entwicklung in .NET für den Desktop. Avalonia hat WPF allerdings nicht blind nachgebaut, sondern an vielen Stellen weiterentwickelt und verbessert. Man könnte es auch das bessere WPF nennen.
Die hohe Ähnlichkeit zu WPF sehen wir beispielhaft am XAML-Code eines Fensters in Listing 1. Dieser Code könnte genauso fast eins zu eins in WPF genutzt werden. Die XAML-Syntax ist gleich, die Namespaces sind überwiegend gleich und auch die hier verwendeten Controls sind gleich. Der einzige Unterschied ist der Namespace https://github.com/avaloniaui in der ersten Zeile.
<Window xmlns="https://github.com/avaloniaui"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d" d:DesignWidth="800" d:DesignHeight="450"
x:Class="Testing.AvaloniaArticle.MainWindow"
Title="Greeting">
<TextBlock HorizontalAlignment="Center"
VerticalAlignment="Center"
FontSize="36"
Text="Hello, Avalonia!" />
</Window>
Eine IDE auswählen
Bei der Auswahl der IDE steht für die meisten C#-Entwickler:innen Visual Studio von Microsoft ganz oben auf der Liste. Das Avalonia-Team bietet hierfür ein Plug-in an, das alle notwendigen Features wie XAML-IntelliSense oder Live-Preview mitbringt. Speziell für die Entwicklung mit Avalonia steht mit der IDE Rider von JetBrains eine weitere Möglichkeit zur Verfügung. Das Besondere daran ist, dass damit auch unter Linux und macOS entwickelt werden kann und es eine hervorragende Unterstützung für Avalonia mitbringt, ohne ein Plug-in installieren zu müssen. Die Firma JetBrains nutzt Avalonia selbst und hat eigene Applikationen wie dotTrace und dotMemory mit Hilfe von Avalonia für macOS und Linux fit gemacht. Aus diesem Grund haben sie die notwendige Unterstützung in der IDE selbst in die Hand genommen.
Als dritte Alternative ist es auch möglich, Avalonia-Applikationen mit Visual Studio Code von Microsoft zu entwickeln. Auch hier stellt das Avalonia-Team ein Plug-in bereit, weist aber darauf hin, dass man hier im Vergleich zu den anderen IDEs die schlechteste Unterstützung für Avalonia vorfinden wird [1].
Mit Avalonia starten
Avalonia stellt mehrere Templates bereit, mit denen wir starten können. Diese werden vom Avalonia-Team in einem separatem GitHub-Repository gepflegt [2]. Mit dem Kommandozeilenbefehl dotnet new install Avalonia.Templates werden sie installiert. Zum Zeitpunkt der Veröffentlichung dieses Artikels erhalten wir damit folgende Templates:
- Avalonia .NET App
- Avalonia .NET MVVM App
- Avalonia Cross Platform Application
Falls wir für Linux und/oder macOS entwickeln wollen, blicken wir womöglich zuerst auf die letzte Variante, Avalonia Cross Platform Application. Tatsächlich wäre aber die erste oder die zweite Variante sinnvoller. Hintergrund ist, dass es sich dabei um die Templates für reine Desktopapplikationen handelt. Solche sind bei Avalonia von vornherein Cross-Platform, also unter Windows, Linux und macOS lauffähig. Der Begriff „Cross-Platform“ im letztgenannten Template geht noch weiter, es zielt zusätzlich auf Android, iOS und den Browser. Für den Einstieg eignet sich das Template Avalonia .NET App sehr gut.
Es gibt noch eine weitere Frage, die es an dieser Stelle zu klären gilt. Wir können CompiledBindings für unsere Applikation nutzen. Standardmäßig ist das Häkchen dafür beim Template aktiv. Es handelt sich um keine endgültige Entscheidung, es empfiehlt sich aber, es immer aktiv zu lassen. CompiledBindings sorgen dafür, dass die Bindings im XAML-Code kompiliert werden – anders als etwa bei WPF. Bei WPF werden Bindings mittels Reflection zur Laufzeit aufgelöst. CompiledBindings bringen uns eine bessere Performance. Zusätzlich bekommen wir beim Kompilieren bereits Feedback in Form von Compilerfehlern, falls es etwa Tippfehler gibt.
Das CompiledBinding erklärt
Technisch basiert das CompiledBinding auf Codegenerierung. Diese beginnt allerdings nicht beim Binding, sondern bereits bei den XAML-Dateien. Anders als bei WPF werden XAML-Dateien nicht in das Zwischenformat BAML übersetzt, sondern direkt in C#-Code – eine der vielen Performanceverbesserungen gegenüber WPF.
Zur Veranschaulichung modifizieren wir das Beispielfenster aus Listing 1 so, dass die Begrüßung nicht fest in XAML hinterlegt ist, sondern aus einem ViewModel kommt. Das ViewModel dazu ist denkbar einfach, da wir keinerlei Änderungsbenachrichtigung (INotifyPropertyChanged) für diesen Zwecke implementieren müssen. Die Klasse MainWindowViewModel in Listing 2 ist völlig ausreichend.
public class MainWindowViewModel
{
public string Greeting => "Hello, Avalonia!";
}
In Listing 3 sehen wir, welche Änderungen in XAML notwendig sind, um das CompiledBinding zur Anbindung des MainWindowViewModel zu nutzen. Der wesentliche Unterschied ist das Setzen der Eigenschaft x:DataType. Damit sagen wir dem Compiler, welchen Typ wir bei dem gebundenen DataContext erwarten.
<Window ...
xmlns:local="clr-namespace:Testing.AvaloniaArticle"
x:DataType="local:MainWindowViewModel">
<TextBlock ...
Text="{Binding Greeting}" />
</Window>
Damit das Beispiel funktioniert, darf nicht vergessen werden, eine Instanz des MainWindowViewModel zu erstellen und der Eigenschaft DataContext des Hauptfensters zuzuweisen. An dieser Stelle reagiert Avalonia exakt so wie WPF.
Ein MVVM-Framework auswählen
MVVM (Model View ViewModel) ist bei XAML-Frameworks nach wie vor das beliebteste Pattern, das gilt auch für Avalonia. Bei der Auswahl des MVVM-Frameworks sind folgende zwei Varianten für Avalonia-Projekte am häufigsten anzutreffen:
- CommunityToolkit Mvvm
- ReactiveUI
Aus Sicht des Autors ist es meist das Einfachste, mit CommunityToolkit.Mvvm zu starten. ReativeUI bietet zwar mehr Features und hat mit dem NuGet-Paket Avalonia.ReactiveUI eine sehr gute Integration in Avalonia, aber die Einstiegshürde ist höher, da ReactiveUI auf den Reactive Extensions for .NET aufbaut. In diesem Artikel wird aus Gründen des Umfangs nicht tiefer darauf eingegangen. Es wäre aber ratsam, ReactiveUI nur dann zu nutzen, wenn ein Verständnis der Reactive Extensions for .NET vorliegt.
ZUM NEWSLETTER
Regelmäßig News zur Konferenz und der .NET-Community
CommunityToolkit.Mvvm kommt dagegen leichtgewichtig daher und kümmert sich im Wesentlichen um die für das MVVM-Pattern notwendige Implementierung von INotifyPropertyChanged und INotifyDataErrorInfo. Zusätzlich bringt es Klassen für synchrone und asynchrone Commands und weitere eher kleine Hilfsmittel mit. Eine Besonderheit des CommunityToolkit.Mvvm ist die Nutzung von Roslyn Source Generators, um typischen Boilerplate-Code rund um INotifyPropertyChanged-Implementierungen zu generieren.
In Listing 4 sehen wir das CommunityToolkit.Mvvm zusammen mit Avalonia in Aktion. Das MainWindowViewModel erweitern wir um das Property Name, das direkt Einfluss auf das Property Greeting hat. Wir definieren dafür lediglich den Member _name, um das Property kümmert sich das CommunitityToolkit per Source Generator selbst. Das Ereignis PropertyChanged müssen wir ebenfalls nicht selbst auslösen – die Attribute ObservableProperty und NotifyPropertyChangedFor sagen dem CommunityToolkit, wie es PropertyChanged auslösen soll. Im Hintergrund wird das Property Name durch das CommunityToolkit generiert, darin wird PropertyChanged für Name und Greeting aufgerufen. Anschließend brauchen wir im XAML-Code nur noch dagegen zu binden.
// MainWindowViewModel.cs
public partial class MainWindowViewModel : ObservableObject
{
[ObservableProperty]
[NotifyPropertyChangedFor(nameof(Greeting))]
private string _name = string.Empty;
public string Greeting => string.IsNullOrEmpty(this.Name)
? string.Empty
: $"Hello, {this.Name}";
}
// MainWindow.axaml
<Window ...>
<Border VerticalAlignment="Center" HorizontalAlignment="Center"
Classes="InputArea">
<StackPanel Orientation="Vertical">
<StackPanel Orientation="Horizontal">
<TextBlock Classes="Label"
Text="Name: " />
<TextBox Text="{Binding Name}" />
</StackPanel>
<StackPanel Orientation="Horizontal">
<TextBlock Classes="Label"
Text="Greeting: " />
<TextBox Text="{Binding Greeting}" />
</StackPanel>
</StackPanel>
</Border>
</Window>
Styling mit Inspiration vom Web
Einer der größten Unterschiede im XAML-Code zwischen WPF und Avalonia ist das Styling-System. Anders als bei anderen XAML-Frameworks wie WPF wurde bei Avalonia das Verhalten von CSS nachgebaut. Ein Style ersetzt also das Styling eines Controls nicht komplett, sondern ergänzt es. Dabei können beliebig viele Styles auf ein und dasselbe Control wirken.
Listing 5 soll hierzu einen ersten Eindruck geben, es definiert einen Style für das vorangegangene Beispiel aus Listing 4. Jeder Style definiert über einen Selector, auf welche Controls er wirkt. Der einfachste Fall ist die Angabe des Typnamens, hier im Beispiel gehen wir bei Border.InputArea bereits etwas weiter. Border ist der Typ des Controls, InputArea ist der Klassenname (siehe Eigenschaft Classes bei dem Border-Control in Listing 4). Innerhalb des Styles definieren wir weitere sogenannte Nested Styles, die auf Child Controls wirken. Das Ergebnis sehen wir in Abbildung 1.
<Style Selector="Border.InputArea">
<Setter Property="Background" Value="#88888888" />
<Setter Property="Padding" Value="10" />
<Setter Property="CornerRadius" Value="10" />
<Style Selector="^ TextBox">
<Setter Property="Width" Value="250" />
</Style>
<Style Selector="^ StackPanel">
<Setter Property="Spacing" Value="5" />
</Style>
<Style Selector="^ TextBlock.Label">
<Setter Property="Width" Value="100" />
<Setter Property="VerticalAlignment" Value="Center" />
</Style>
</Style>
Abb. 1: Begrüßungsdialog mit angewendetem Styling
Hier am Beispiel sehen wir nur einen kleinen Bruchteil der Möglichkeiten des Styling-Systems von Avalonia. Das Avalonia-Team beschreibt in der Dokumentation eine lange Liste von möglichen Selektoren [3] – ein Blick lohnt sich. Das System wird ebenso regelmäßig erweitert, etwa durch die mit Version 11.3 eingeführten und an CSS Media Queries angelehnten Container Queries.
Avalonia DevTools
Features wie Hot Reload oder als Alternative einen visuellen Designer, wie wir ihn etwa noch aus den guten alten WinForms-Zeiten kennen, fehlen in Avalonia. Mit Avalonia Accelerate arbeitet das Avalonia-Team zurzeit genau an diesen Punkten. Avalonia Accelerate ist ein kostenpflichtiges Produkt, das Zusatzfeatures für Entwickler:innen von Avalonia-Applikationen enthält.
Im Open-Source-Paket von Avalonia werden schon länger integrierte DevTools angeboten, die über das NuGet-Paket Avalonia.Diagnostics bereitgestellt werden. Die beschriebenen Templates binden das NuGet-Paket direkt mit ein. Ein Tastendruck auf F12 reicht, um das DevTools-Fenster zu öffnen. Die DevTools helfen bei mehreren Aufgaben, so lassen sich Logical Tree und Visual Tree prüfen, ob sie die erwarteten Inhalte aufweisen. Der Logical Tree bildet dabei die Baumstruktur aus den XAML-Dateien ab. Der Visual Tree zeigt, was tatsächlich am Bildschirm gerendert wird – aufgrund von Templating i. d. R. deutlich mehr. Abbildung 2 zeigt, wie die DevTools von Avalonia aussehen.
Abb. 2: Avalonia DevTools
Noch ein Hinweis an alle Leser:innen, die Hot Reload oder einen Designer vermissen. In den DevTools können Werte von Eigenschaften direkt live geändert werden. Damit sieht man sofort, welche Änderungen zu welchen Effekten auf der Benutzeroberfläche führen.
ZUM NEWSLETTER
Regelmäßig News zur Konferenz und der .NET-Community
Neben der Anzeige der Baumstrukturen bieten die DevTools weitere Features wie ein Tracking der von den Controls ausgelösten Events. Ebenfalls können performancerelevante Kennzahlen wie Rendering- und Layoutzeit eingeblendet werden. Unterm Strich sind die DevTools auf jeden Fall mehr als einen Blick wert.
Architektur von Avalonia
Nachdem wir uns in diesem Artikel mit einigen Eigenschaften von Avalonia beschäftigt haben, möchten wir unseren Blick noch einmal von der Vogelperspektive auf das UI-Framework werfen. Das hilft uns dabei, das UI-Framework noch besser zu verstehen und die Vor- und Nachteile gegenüber anderen UI-Frameworks abschätzen zu können.
Abbildung 3 gibt uns dafür einen groben Überblick. Ganz oben steht dabei Avalonia zusammen mit allen in Avalonia zur Verfügung gestellten Controls. Darunter liegt Skia. Skia ist ein Open-Source-2D-Rendering-Framework von Google, das unter anderem auch in modernen Browsern wie Google Chrome eingesetzt wird. Ähnlich wie auch Flutter nutzt Avalonia Skia zum Rendering aller Controls. Unterhalb von Skia liegt entweder die Core CLR oder die Mono Runtime – je nachdem, auf welcher Plattform oder auf welchem Gerät wir eine Avalonia-Applikation ausführen.
Abb. 3: Architektur von Avalonia (eigene Darstellung nach [4])
Als logische Konsequenz aus dieser Architektur verhalten sich Avalonia-Applikationen auf allen unterstützten Plattformen weitgehend gleich und sehen gleich aus. Im Vergleich zu Avalonia gibt es auch andere UI-Frameworks, die einen ähnlichen Ansatz verfolgen. WPF etwa rendert auch alle Controls selbst, baut allerdings auf das plattformabhängige Direct3D auf. Auch bei anderen Programmiersprachen finden wir Beispiele, etwa beim bereits angesprochenen Flutter von Google oder dem für C++-Entwickler:innen gedachten Qt.
Im Vergleich zu anderen UI-Frameworks in .NET ist der Ansatz von Avalonia nicht häufig anzutreffen. .NET MAUI beispielsweise geht einen anderen Weg. Dort werden Controls nicht selbst gerendert, sondern die jeweiligen nativen Controls der Plattformen genutzt. Ein Vorteil davon ist das native Look and Feel, ein Nachteil ist der deutlich größere Testaufwand. Aus Sicht des Autors ist es wichtig, solche Unterschiede zu kennen, sobald es um die Entscheidung für oder gegen ein UI-Framework geht.
Stärke am Desktop, Potenzial auf anderen Plattformen
Historisch hat Avalonia seine größte Stärke am Desktop. Die Unterstützung für die mobilen Plattformen Android und iOS ist zusammen mit der Unterstützung für den Browser erst in Version 11 am 7. Juli 2023 veröffentlicht worden. Entscheidet man sich auf diesen Plattformen für Avalonia, muss man damit rechnen, auf die eine oder andere Lücke zu stoßen. So bietet Avalonia von Haus aus kein Navigations-Control mit Behandlung des Zurück-Knopfs – andere UI-Frameworks mit Fokus auf mobile Plattformen wie .NET MAUI haben hier mehr zu bieten.
Das Potenzial, das Avalonia auf mobilen Plattformen hat, kann man mit einem Blick auf Flutter erkennen. Flutter ist von seiner Architektur her sehr ähnlich zu Avalonia und ist insbesondere für Cross-Platform-Applikationen für mobile Geräte ein sehr beliebtes UI-Framework außerhalb der .NET-Welt.
Die Community rund um Avalonia
Avalonia ist nicht nur aus der Community entstanden, die Community ist auch eine der größten Stärken des UI-Frameworks. Das Avalonia-Team pflegt eine Liste von Anlaufstellen, um sich mit der Community auszutauschen [5]. Dazu gehören ein Forum innerhalb des GitHub-Projekts auf Basis von GitHub Discussions und diverse Chats via Telegram und Discord.
Daneben existiert eine große Zahl von Open-Source-Projekten rund um Avalonia. Das GitHub-Projekt awesome-avalonia [6] ist ein guter Startpunkt, um Projekte zu finden, die für das eigene Projekt relevant sind.
Die Zukunft von Avalonia
Avalonia ist ein Open-Source-Projekt – mit dieser Tatsache steht für viele Interessierte die Frage im Raum, inwieweit das Team hinter Avalonia langfristig das Framework pflegt. Erfreulicherweise veröffentlicht Mike James, der CEO von Avalonia, regelmäßig Informationen darüber, wo die Prioritäten des Teams liegen und wie das Team aus Businesssicht aufgestellt ist. So beschreibt er in einem Blogpost vom 2. Dezember 2024, wie sich das Team zu diesem Zeitpunkt finanziert [7]. Der größte Einnahmeblock ist Avalonia XPF – ein kommerzielles Schwesterframework, das die Migration von WPF-Anwendungen auf andere Betriebssysteme erleichtert und zugleich einen Migrationspfad hin zu Avalonia bietet. Dieser Anteil dürfte sich im Juni 2025 geändert haben, denn zu diesem Zeitpunkt hat das Avalonia-Team eine 3 Millionen US-Dollar große Spende von der kanadischen Firma Devolutions erhalten [8].
Fazit
Avalonia gibt uns alle notwendigen Werkzeuge an die Hand, um Benutzeroberflächen für die verschiedensten Plattformen zu entwickeln. Insbesondere finden sich Entwickler:innen mit Erfahrung in XAML-basierten Frameworks wie WPF schnell zurecht. Aber auch der Umstieg von anderen Frameworks wie dem nach wie vor verbreiteten Windows Forms, ist kein Ding der Unmöglichkeit – hier muss allerdings Zeit zum Lernen der XAML-Syntax und des MVVM-Patterns hinzugerechnet werden.
Gerade der Support für Linux dürfte für viele Lesende spannend sein, da Microsoft selbst hier eine Lücke hinterlässt. Linux spielt in verschiedenen Bereichen der Industrie und insbesondere in der Embedded-Welt eine sehr große Rolle. Avalonia kann hier als mächtiges UI-Framework mit ebenso mächtigem .NET-Unterbau punkten.
Das Avalonia-Team stellt sich aus Sicht des Autors sinnvoll für die Zukunft auf. Sie erweitern das Open-Source-Paket mit Avalonia Accelerate um kommerzielle Zusatzkomponenten, die für professionelle Entwickler:innen zusätzliche Produktivität und Features liefern. Auch Avalonia XPF kann gerade bei einer größeren Migration eines WPF-Projekts spannend sein. Ganz nebenbei finanzieren diese Produkte die Weiterentwicklung am Open-Source-Paket Avalonia selbst, das auch für kommerzielle Projekte kostenlos zur Verfügung steht.
Frequently Asked Questions (FAQ)
1. Was ist Avalonia und wie unterscheidet es sich von WPF?
Avalonia ist ein Open-Source, Cross-Platform UI-Framework auf .NET-Basis, das von WPF inspiriert ist. Syntax und Controls sind nahezu identisch zu WPF, allerdings wurde die Architektur modernisiert und die Plattformunterstützung erheblich erweitert.
2. Welche Plattformen unterstützt Avalonia?
Ursprünglich unterstützte Avalonia nur Windows, macOS und Linux. Seit Version 11 (Juli 2023) sind zusätzlich Android, iOS sowie Browser-basierte Anwendungen (über WebAssembly) möglich.
3. Welche IDEs eignen sich für die Entwicklung mit Avalonia?
Visual Studio bietet mit einem offiziellen Plugin XAML-IntelliSense und Live Preview. JetBrains Rider hat die beste Integration out-of-the-box. Visual Studio Code kann ebenfalls genutzt werden, ist aber im Funktionsumfang am wenigsten komplett.
4. Wie startet man ein neues Avalonia-Projekt?
Über dotnet new install Avalonia.Templates lassen sich offizielle Templates installieren. Für Desktop empfiehlt sich „Avalonia .NET App“ oder „Avalonia .NET MVVM App“. Wer zusätzlich Android, iOS und Browser ansprechen möchte, nutzt „Avalonia Cross Platform Application“.
5. Was sind CompiledBindings und welche Vorteile bieten sie?
CompiledBindings generieren aus XAML bereits zur Compile-Zeit C#-Code. Dadurch wird Reflexion zur Laufzeit vermieden, die Performance steigt und Bindungsfehler werden bereits beim Kompilieren erkannt.
6. Welche MVVM-Frameworks werden mit Avalonia häufig eingesetzt?
Am verbreitetsten sind CommunityToolkit.Mvvm und ReactiveUI. Ersteres ist leichtgewichtig und nutzt Source Generators, während ReactiveUI sehr mächtig ist, aber auf Reactive Extensions basiert und eine höhere Lernkurve hat.
7. Wie funktioniert das Styling in Avalonia?
Avalonia orientiert sich am CSS-Modell. Styles können per Typ- oder Klassenselektoren gesetzt werden, mehrere Styles pro Control sind möglich, ebenso wie verschachtelte Styles. Mit Version 11.3 kamen moderne Features wie CSS-ähnliche Container Queries hinzu.
8. Welche Entwickler-Tools bietet Avalonia und was ist Avalonia Accelerate?
Mit Avalonia.Diagnostics stehen Open-Source DevTools bereit, die u. a. den Logical Tree, Visual Tree, Events und Performance-Daten live inspizieren lassen. Avalonia Accelerate ist ein kostenpflichtiges Zusatzpaket mit erweiterten Features wie Visual Designers und verbessertem Hot Reload.
Links & Literatur
[1] https://docs.avaloniaui.net/docs/get-started/set-up-an-editor
[2] https://github.com/AvaloniaUI/avalonia-dotnet-templates
[3] https://docs.avaloniaui.net/docs/reference/styles/style-selector-syntax
[4] https://docs.avaloniaui.net/docs/overview/what-is-avalonia
[5] https://docs.avaloniaui.net/docs/community
[6] https://github.com/AvaloniaCommunity/awesome-avalonia
[7] https://avaloniaui.net/blog/avalonia-ui-in-2024-growth-challenges-and-the-road-ahead
[8] https://github.com/AvaloniaUI/Avalonia/discussions/19108
