Orchis Theme: A Material Design GTK Theme for GNOME Desktops

What Orchis Theme Solves for GNOME Users

GNOME ships with Adwaita, and changing its look means replacing the GTK stylesheet rather than toggling a setting. Orchis is one answer to that: a Material Design theme for GNOME and GTK based desktop environments, built from SCSS sources and distributed as a repository you clone and run a script from. The README describes it as based on nana-4's materia-theme, so the visual language is inherited rather than designed from zero.

The audience is narrow and specific. You need GTK 3.20 or newer, gnome-themes-extra (or gnome-themes-standard), a Murrine engine package, and sassc as a build dependency. That list tells you the theme targets GTK 3 applications primarily, with separate handling for GTK 4 and libadwaita through a linking step. If you run a desktop that does not use GTK for its shell and core apps, the theme will only reach the GTK applications you launch, not the panel, the window manager or the system menus.

The payoff is control. Rather than one fixed look, the installer exposes color variants (default, purple, pink, red, orange, yellow, green, teal, grey, and all), light, dark or standard modes, and compact or standard sizing. You can also change the round corner radius with a pixel value, and swap the shell panel activities icon for a distribution-specific one. That is more configuration surface than most GTK themes offer.

How the Installer, SCSS Sources and Shell Variants Fit Together

The repository layout explains the mechanism. The top level holds install.sh, core.sh, gtkrc.sh and parse-sass.sh, alongside src/, release/ and wallpaper/. The SCSS sources live in src/, and parse-sass.sh is the build step that turns them into CSS. install.sh is the entry point that most users touch; it accepts flags that select which variants to build and where to put them.

The default destination is $HOME/.themes, and the default theme name is Orchis. Because the installer builds from source rather than downloading prebuilt archives, sassc has to be present before the script can produce anything. The release/ directory suggests prebuilt output is also kept in the repository, but the README's installation section only documents the script path.

GNOME Shell theming is version sensitive, and the script handles that with a --shell flag offering 38, 40, 42, 44, 46, 47 and 48. Without the flag, the README states the script detects the shell version and installs the matching theme. That detection is the part most likely to fail on unusual setups, which is why the manual override exists.

The libadwaita situation is worth understanding before you install. The README explains that ./install.sh -l links a selected Orchis gtk-4.0 theme from $HOME/.themes to $HOME/.config/gtk-4.0/gtk.css. That is a symlink, not a theme registration, and the README says plainly that it will not support changing the theme through GNOME Tweaks. To use a different variant for libadwaita, you re-run the installer with the color flags you want, for example a dark or dark purple link.

Installing Orchis Theme on Ubuntu, Fedora and Other GTK Desktops

The README gives a manual installation path: clone the repository, then run the install script from its root. The script builds the theme variants and copies them into $HOME/.themes.

./install.sh

After that completes, the README's default is a blue, all-variants install under the name Orchis. You then select the theme through your desktop's appearance settings or GNOME Tweaks; the README does not walk through that selection step, so treat it as the point where you confirm the build landed in $HOME/.themes.

To pick specific variants rather than everything, pass the color and mode flags. This builds only the dark purple variant and links it for libadwaita at the same time.

./install.sh -c dark -t purple -l

The -l flag is the libadwaita fix for GNOME Shell 42.0 and newer. It creates the link from the chosen gtk-4.0 theme to $HOME/.config/gtk-4.0/gtk.css. The README notes the default light version is installed when you pass -l without a color flag.

Flatpak applications do not see the host's GTK config directories by default. The README gives an override for that.

sudo flatpak override --filesystem=xdg-config/gtk-3.0 && sudo flatpak override --filesystem=xdg-config/gtk-4.0

Finally, the script can remove what it installed. The README lists -r and -u as uninstall flags.

./install.sh -r

Running ./install.sh -h prints the full option list, which is the safest way to confirm flag names on the version you cloned.

Where Orchis Theme Stops Being the Right Tool

The README describes Orchis as a theme for GNOME and GTK based desktop environments, and that boundary is real. The related searches show people asking about Orchis on KDE, Cinnamon and XFCE, but nothing in the README or the repository layout indicates support for those desktops. KDE Plasma does not use GTK for its shell, so a GTK theme cannot restyle it. Cinnamon and XFCE use GTK for applications, but their panels and window managers read their own theme formats, and the repository contains no Cinnamon or XFCE panel assets.

The libadwaita link is the second sharp edge. Because it is a symlink to $HOME/.config/gtk-4.0/gtk.css rather than an installed theme, GNOME Tweaks cannot switch between Orchis variants for libadwaita applications. The README states this directly. If you like changing themes often, or you want the theme picker to control GTK 4 apps, this design will frustrate you. The workaround is to re-run the installer with different flags each time.

Build dependencies are the third constraint. sassc is required, and if it is missing the script cannot compile the SCSS sources. The Murrine engine package name differs by distribution, and the README lists five variants: gtk-engine-murrine on Arch, gtk-murrine-engine on Fedora, gtk2-engine-murrine on openSUSE, and gtk2-engines-murrine on Debian and Ubuntu. Getting the wrong package means GTK 2 applications styled by the theme will not render correctly.

Finally, there is no rollback mechanism documented in the README beyond the uninstall flags. If a variant breaks an application, you remove the theme and reinstall with different flags rather than reverting to a previous build.

Orchis Theme Against Materia and Adwaita

Orchis is explicitly based on nana-4's materia-theme, so the honest comparison is with its own ancestor. Materia established the Material Design approach for GTK; Orchis keeps that foundation and adds its own variant matrix, including color options, compact sizing, a black variant, macOS-style window buttons, and Nord and Dracula color schemes. The tweaks list in the README is where the two projects diverge most: Orchis treats variant selection as a first-class installer concern.

The other reference point is Adwaita, which ships with GNOME and requires no installation. Adwaita tracks GNOME releases closely and works with libadwaita applications without any linking step, because it is the default. Orchis trades that automatic integration for visual choice. If your priority is that GTK 4 and libadwaita applications follow your theme without manual intervention, Adwaita is the lower-friction option. If you want Material Design styling and are willing to run the installer again when you change your mind, Orchis gives you a wider set of looks from one codebase.

A third path some users take is building a theme from the same SCSS tooling themselves. The repository's parse-sass.sh and src/ directory make that possible, but the README does not document the SCSS structure, so you would be reading the sources rather than following instructions.

Maintenance, Licensing and Upgrade Cost for Orchis Theme

The repository is not archived, and the last push was on 2026-09-14. The most recent release listed is from 2026-07-07, with earlier releases in 2025-04-25 and 2024-11-03. That is a release cadence measured in months rather than weeks, which matters if you depend on the theme tracking new GNOME Shell versions quickly. The installer's --shell flag already lists 47 and 48, so recent shell versions are covered in the current tree.

Upgrading means pulling the repository and re-running install.sh. Because the theme is built from SCSS at install time, there is no package manager to handle versioning, no dependency resolution, and no automatic update. You re-run the script, and the new files land in $HOME/.themes. If you used the -l flag, you also re-run that link step, since the symlink points at a specific built variant.

Licensing is GPL-3.0, per the repository's COPYING file and the licence identifier. For personal desktop use this is unremarkable. If you plan to redistribute the theme, bundle it into a distribution image, or ship a modified version, GPL-3.0's copyleft terms apply to derivative works, and you should read COPYING rather than rely on a summary. This is a description of the licence, not legal advice.

The practical upgrade cost is low but manual: one git pull and one script run, plus a re-link if you use libadwaita. The cost of not upgrading is that a new GNOME Shell release may not be covered until the repository adds it.

Editorial conclusion

Adopt Orchis if you run GNOME with GTK 3.20 or newer, want a Material Design look, and are willing to install sassc and the Murrine engine before building. Do not adopt it if you run KDE Plasma, Cinnamon or XFCE as your primary desktop, since the README and repository only describe GNOME and GTK integration. Before installing, verify your GTK version, your shell version if you use GNOME Shell, and whether you need the libadwaita link. The install script writes into $HOME/.themes by default, so check that directory first if you already have themes there.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. vinceliuice/Orchis-theme on GitHub