Devolutions.AvaloniaTheme.Linux 2026.8.25

Custom Avalonia Themes developed by Devolutions

Linux Theme [Work in Progress]

This theme is currently based on Avalonia.Themes.Fluent, both as a fallback for any controls not covered yet and as starting point for our style definitions targeting a Linux look similar to Ubuntu’s default “Yaru” GTK theme..

While we are prioritizing controls for Devolutions Remote Desktop Manager, we welcome contributions from the Avalonia community to add more controls.

• Installation
• Styled Controls
  • Available in the current build
    • ComboBox
      • ComboBoxItem
  • 🚧 In progress ...
    • Dark mode support
  • 🔮 Next on the road map ...

Installation

Avalonia 12 required. Packages 2026.6.17-avalonia12 and later require Avalonia 12. The last stable release compatible with Avalonia 11 is 2026.6.16.

Install the Devolutions.AvaloniaTheme.Linux package via NuGet:

Install-Package Devolutions.AvaloniaTheme.Linux

or .NET

dotnet add package Devolutions.AvaloniaTheme.Linux

In your App.axaml, replace the existing theme (e.g. <FluentTheme /> or <SimpleTheme />) with the Linux theme:

<Application ...>
  <Application.Styles>
     <DevolutionsLinuxYaruTheme />
  </Application.Styles>
</Application>

Menu pack (menu controls only)

Use the menu pack when you only want Linux menu styling but not the full <DevolutionsLinuxYaruTheme /> (e.g. to give consistent Menu chrome to custom-branded sections of your app).

The Linux theme has no OS-dependent sub-themes, so — unlike the MacOS pack, which has to pick between its classic and LiquidGlass variants at runtime — this pack is a plain style include, the same shape as the DevExpress pack.

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

    
    <StyleInclude Source="avares://Devolutions.AvaloniaTheme.Linux/Controls/MenuPack.styles.axaml" />
  </Application.Styles>
</Application>

Exact menu pack URI:

avares://Devolutions.AvaloniaTheme.Linux/Controls/MenuPack.styles.axaml

Prerequisites and caveats:

• FluentTheme must be loaded application-wide, in Application.Styles — not scoped to a subtree. The Linux control themes build on Fluent's base templates, and HorizontalMenuItem derives from Fluent's FluentTopLevelMenuItem, which is resolved when the menu template is built.
• This pack includes styling for ContextMenu, MenuFlyoutPresenter, Menu, MenuItem, and the menu-specific helper styles (Menu.styles.axaml, Separator.styles.axaml, MenuSvg.styles.axaml).
• If you need full control coverage, use <DevolutionsLinuxYaruTheme /> instead.

Resource contract

All menu tokens live in a single shared file, Accents/MenuResources.axaml, which is included by both the full theme and the menu pack. There is one source of truth, so the pack can never drift from the full theme.

Two rules make the pack safe to layer over a host theme you do not control:

1. Every menu token the pack owns is prefixed LinuxMenu — no token can collide with, or be silently overridden by, the host theme's keys.

   This applies to the tokens, not to every resource in the pack. The pack also ships ControlThemes, and those are deliberately not prefixed: the implicit ones ({x:Type MenuItem}, {x:Type Menu}, {x:Type ContextMenu}, {x:Type MenuFlyoutPresenter}) must keep their x:Type keys, since that is the mechanism by which the pack restyles menus at all. Two named ones — HorizontalMenuItem and HorizontalMenuFlyoutPresenter — are also unprefixed and share their names with the other Devolutions themes; whichever is nearest in scope wins, so the pack's versions apply within the scope the pack is added to.

2. Values are pinned literals, never aliases. Menu tokens do not resolve through generic theme-wide or Fluent-owned keys. A host theme that redefines e.g. MenuFlyoutItemForeground or FlyoutThemeMaxWidth cannot move menu visuals.

Rule 2 mattered more here than for the other packs. The Linux menu templates were derived from Fluent and read Fluent's own generic keys directly (MenuFlyoutItemBackground, MenuFlyoutPresenterBackground, CheckMarkPathData, ...). That is invisible under the full theme, but layered over another theme every one of those keys resolved to the host's value, so the "Linux" menus rendered in the host's colours. Those templates now read LinuxMenu* tokens only.

Inherited from the host (by design):

Typography is pinned, not inherited. LinuxMenuFontFamily / LinuxMenuFontSize / LinuxMenuFontWeight are owned by the pack. The point of the pack is that menus in a branded or opted-out section still match the platform-themed menus elsewhere in the same app; inheriting the host's font defeats that, and pinning also keeps menu geometry identical across hosts (font metrics change row heights).

Row geometry, typography and normal-state colours are applied at Style level, not only in the MenuItem ControlTheme. Host themes set menu metrics with Styles of their own, and in Avalonia a Style setter outranks a ControlTheme setter — so a ControlTheme alone would let the host resize menu rows, restyle their text, or recolour them.

This sealing is applied in two places, because one selector cannot cover both: popup rows and submenu items are descendants of ContextMenu / MenuFlyoutPresenter / MenuItem, whereas menu-bar items are direct children of Menu and would otherwise be left exposed. The two blocks pin the same typography but different geometry, since menu-bar items have their own padding. Only the normal state is sealed there; hover / selected / disabled colours are applied to template children, which a host MenuItem style cannot reach.

SVG menu icons are recoloured by the pack. Menu icons ship with an embedded fill, so MenuSvg.styles.axaml applies LinuxMenuSvgItemDefaultCss / LinuxMenuSvgItemDisabledCss per variant. The full theme includes the same file from GlobalStyles.axaml, so the two cannot drift.

The pack styles menu content only. It deliberately does not ship a Separator ControlTheme: that resource is keyed {x:Type Separator}, so merging it would restyle every separator in your app rather than just menu ones. Menu separators instead reuse the host's separator template — identical across Fluent, MacOS, Linux and DevExpress — with every template-bound property pinned inside the menu-scoped selector.

Overriding a token. Because tokens are prefixed, you can retarget any single value without affecting the rest of your app:

<Application ...>
  <Application.Resources>
    
    <SolidColorBrush x:Key="LinuxMenuSeparatorBrush" Color="#ff0000" />
  </Application.Resources>

  <Application.Styles>
    <FluentTheme />
    <StyleInclude Source="avares://Devolutions.AvaloniaTheme.Linux/Controls/MenuPack.styles.axaml" />
  </Application.Styles>
</Application>

The two go in different collections — the token override is a resource, the pack is a style — and the relative order of the collections does not matter.

The override must not sit in an outer scope relative to the pack. Resource lookup walks up from the control and stops at the first match, and an element's Resources are consulted before its Styles. So an override works when it sits on the same element that carries the pack (as above) or on a descendant, but is silently ignored if the pack is added lower down — e.g. pack on a UserControl, override on the Window. In that case the pack's own token is found first and your value never applies.

These rules are enforced by LinuxMenuPackContractTests in the visual test project, which asserts that every LinuxMenu* token resolves identically under the full theme and under "pack over a foreign host", that a hostile host theme cannot leak into any of them, and that the menu templates never read an unowned resource key.

Styled Controls

Below are some screenshots from the SampleApp test and demo pages - feel free to check out the code there for more detailed usage examples. For an always up-to-date visual reference you can also browse the baseline screenshots.