# MoreWaita: an Adwaita companion theme for the apps Adwaita does not cover > MoreWaita is an icon theme that adds to Adwaita rather than replacing it, covering third-party applications and MIME types that the GNOME theme leaves alone, in the Adwaita flat perspective but with brand colours kept intact. It is built with Meson, ships fixed and scalable sizes, and is installed as a companion theme alongside Adwaita. **somepaulo/MoreWaita** — An expanded Adwaita-styled companion icon theme with extra icons for popular apps and MIME types to complement Gnome Shell's original icons. - Repository: https://github.com/somepaulo/MoreWaita - Stars: 1,117 · Forks: 51 - Language: Meson - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/somepaulo-morewaita ## A companion theme, not a replacement MoreWaita is an expanded Adwaita-styled companion icon theme, with extra icons for popular apps and MIME types, built largely upon the work of GNOME's Adwaita designers and GNOME Circle apps' developers, with inspiration from the Papirus icon theme designers and tinkering from the maintainer and a few others. The word companion is the entire design brief, and the project is explicit about what it means. The goal of MoreWaita is to add to Adwaita, not modify it, and to do roughly what Breeze does for KDE. This theme does not override any Adwaita icons, nor any GNOME Circle apps icons, nor icons that generally fit into the Adwaita paradigm, like Transmission GTK. That last exclusion is worth understanding, because it explains the design of the whole thing. Icons that Adwaita already handles are Adwaita's business, and a theme that started overriding them would fork the desktop's visual language and every upstream update would become a merge conflict. So MoreWaita stays out of the way and covers the gap. The purpose is stated plainly: to provide third-party apps with a consistent look and feel in Gnome Shell. The project is also honest about its size and its ownership. It is currently way less all-inclusive than many others, but the aim is to be on par with Papirus some day. However, this is mostly a one-man hobby effort, albeit with some greatly appreciated help, so suggestions, requests, pull requests and contributions are very welcome, and the project asks you to read CONTRIBUTING.md before submitting pull requests. The licence is GPL v3, and the repository is GPL-3.0 licensed. ## Adwaita's perspective with the brand's own colours The style rules are a small set of principles, and they explain why the icons look the way they do. For most icons, especially branded ones, the general idea is to stay as close as possible to the original icons, to the point of using them in full, and then give them the distinct Adwaita perspective and general flatness. So the shape and the artwork come from the original brand, and the rendering treatment is Adwaita's. The flatness and the perspective are what make an icon look like it belongs next to a GNOME application rather than next to an icon from another theme. And then one deliberate exception. One thing this theme deviates from is the Gnome colour palette in brand icons, because MoreWaita keeps the brand colours. That is the rule that most separates this theme from a strict Adwaita rendering. A GNOME-style icon theme usually recolours everything to the GNOME palette, blue and grey and the accent colours, so the desktop looks uniform. MoreWaita refuses to do that to brand icons, which means a Discord icon is still Discord purple and a Spotify icon is still green. The trade-off is real and worth naming. The desktop looks less uniform than it would with a fully recoloured theme, and the icons are less cohesive as a set. What you get in exchange is that the application is still recognisable at a glance, which for a third-party application is often the point. The theme is built and tested against vanilla Gnome on Arch Linux, and the projects it is tested against in practice are visible in the topics: Arch Linux, Fedora, Ubuntu, and Linux Mint. ## How the icons get into an application, and the .desktop file The most practically useful paragraph in the project summary is the troubleshooting one, and it tells you how icon lookup actually works. If an icon is in the theme, but is not applying to your app, please open an issue and mention the icon name referenced in your app's `.desktop` file. That single sentence explains the whole delivery mechanism. An icon theme does not push icons to applications. The application declares what it is called in its desktop entry, the desktop entry names an icon, and the icon theme lookup finds the matching file by name in one of the theme's size directories. So a theme can only take effect for an application whose icon name it happens to match, and a mismatch shows up as a generic fallback icon rather than an error. This is why the icon list in the project summary is not decorative. The file names are the mechanism. The examples in the summary are all of the form `scalable/apps/.svg`, and they are worth reading as data, because the naming conventions vary in ways that matter. Some are the plain application name, `abiword.svg` and `audacity.svg`. Some carry a reverse-DNS style identifier, `com.github.dalerank.akhenaten.svg` and `io.github.linx_systems.ClamUI.svg` and `dev.bsnes.bsnes.svg`, which is what applications distributed as Flatpak or through a third-party channel tend to use. And some carry a descriptive slug, `com.github.rafostar.Clapper.svg` alongside `com.clapper...`-style names, or a name that encodes a variant, `brave-desktop.svg` and `brave-origin.svg` for the two Brave browsers, `discord.svg` and `discord-canary.svg` for the stable and canary channels, `code-oss.svg` for the Code OSS editor, `alacritty.svg` for the terminal, `calibre.svg` with `calibre-ebook-edit.svg` and `calibre-viewer.svg` for the two Calibre tools, `org.cockpit_project.CockpitClient.svg` for the Cockpit management console, and `carla.svg` with `carla-control.svg` for the simulator and its separate control app. The reverse-DNS names are the interesting ones, because they are the convention for applications that are not part of the distribution and therefore have to use a globally unique identifier to avoid collisions with other themes. The theme covers far more than applications. The description names MIME types as well, which is the other half of what an icon theme does, and the `scalable/` directory in the listing is where the app icons sit alongside other categories. ## The repository is a theme package, not a folder of pictures The top level of the repository shows what a Linux icon theme actually is, and it is more than SVGs. There are the size directories, `16x16/`, `scalable/`, and `symbolic/`, which is the standard icon theme layout. The `16x16/` directory holds fixed size bitmaps, `scalable/` holds vector artwork at whatever resolution the viewer wants, and `symbolic/` holds the monochrome symbolic icons that GNOME uses for buttons and menu items, which are recoloured to match the current theme and the panel background. Then there is `index.theme`, which is the file that makes the directory a theme. It is the metadata descriptor, the thing the icon loader reads to learn the theme's name, its directory structure, and which size directories it provides, and its absence would make the whole tree invisible to the desktop even with thousands of icons in it. `meson.build` is the build system, and the primary language of the repository is recorded as Meson, which tells you the project has moved to a modern, declarative build rather than a hand-written Makefile. Meson is what the major distributions use to package themes, and having the build already in that shape means a packager has little to do. There is also an `install.sh`, and a `Makefile` is not in the listing, which is consistent with the Meson move. The remaining entries are the ones that show a theme being maintained as a project rather than a folder. `PACKAGING.md` is the file that explains how to package the theme, and the `AUTHORS` file credits the people whose work the theme is built on. `CONTRIBUTING.md` is the contribution guide the summary asks you to read before submitting a pull request. The `_dev/` directory is the working directory for the artwork, and `_extras/` holds the additional assets. And the release versions are v49 in December 2025, v50 in October 2026, and v50.1 on 2026-10-05, with the last push on 2026-10-11. So the theme ships on a numbered cadence that tracks the GNOME release cycle, which is how icon themes are usually versioned, since the version number tells you which GNOME release the theme was made for. ## The git tree is ahead of the release, and that matters here There is a line in the project summary that is easy to miss and that changes how you should use this repository. The icons are currently in git, versioned theme releases will be behind most of the time. That is an unusual admission for an icon theme, and it is a practical instruction. The icons in the git tree are the current artwork, while the packaged release is a snapshot taken at some earlier point. So the count of icons you see on the project page is not the count you get from the release tarball. The reason is obvious once you think about how the theme is consumed. A distribution packages the release, and the release is cut and frozen, so its contents lag the repository by however long it has been since the last cut. Meanwhile the artwork keeps moving, with new applications getting icons weekly, and a long tail of fixes. For someone installing the theme, that means you choose between the stable packaged version and the current git tree, and they are not the same. The stable version is what a distribution gives you, what users report bugs against, and what the maintainer can support. The git tree is where the newest icons are, and where unreleased artwork changes can break your desktop in small ways. There is a related detail in the same line about the versioned releases being behind most of the time, which is stronger than a simple lag. It implies the release is not cut on a schedule tied to the artwork, so the gap widens. The practical advice, then, is to treat the release as the supported artefact and the git tree as a preview, and to file issues against the icon name in your application's `.desktop` file as the project asks, since that is the only way the maintainer can find the artwork you are missing. ## Where MoreWaita is the wrong choice The limits are mostly about scope and about what a companion theme cannot do. First, if you want one theme that covers your whole desktop, this is not it. MoreWaita explicitly does not override Adwaita icons or GNOME Circle app icons or icons that fit the Adwaita paradigm. A desktop with a mix of MoreWaita and Adwaita is the intended result, not a compromise, but it does mean the theme cannot be the single source of your icon set. Users who want one coherent set across everything are better served by a full theme such as Papirus, which the project names as its eventual benchmark. Second, coverage is incomplete and the project says so. The theme is way less all-inclusive than many others, with the aim of reaching Papirus parity some day from a one-man hobby effort. If your desktop runs an application with no icon here, you get the generic fallback, and the only fix is a contribution. Third, the brand-colour rule cuts both ways. Keeping brand colours makes applications recognisable, and it also means the set is less visually uniform than a fully recoloured theme. Some users find the mix of GNOME-blue system icons and vividly coloured third-party icons jarring. That is a taste question, but it is the taste question the project has decided, and you can only change it by forking. Fourth, the platform is narrow in the practical sense. The theme is built and tested against vanilla Gnome on Arch Linux. It works on Fedora, Ubuntu, and Linux Mint, which the topics list, but the tested reference is one distribution with one desktop. Icons for applications that are packaged differently on different distributions may resolve differently, and the reverse-DNS naming convention exists precisely because of that variability. Fifth, and this is the one that surprises people, an icon theme cannot add an application. The theme supplies the artwork under a name, and the application has to ask for it by that name in its desktop entry. A third-party application that ships its own icon, or one that is not in the theme, will not look like the rest of your desktop however complete the theme is. The scope of the project is the artwork, not the integration. Sixth, the licensing of the artwork is inherited, not uniform. The theme is GPL v3 and the files carry the upstream designers' copyright, which is why the AUTHORS file exists and why the project credits GNOME's Adwaita designers, GNOME Circle app developers, and the Papirus designers explicitly. If you redistribute the theme, you are redistributing work that has its own terms, and the AUTHORS file is where you find out whose. ## Conclusion MoreWaita fits a GNOME user who runs a lot of non-GNOME software and wants it to look like part of the desktop rather than a set of mismatched icons, and who is comfortable installing a companion theme alongside Adwaita. It is the wrong choice for someone who wants one theme that covers everything, and it is the wrong choice if you need the icons to be complete today. Check three things before you install it: that you understand it is a companion theme and not a replacement, that you read PACKAGING.md, since the repository is more than a directory of SVGs, and that you check the release tag rather than the git tree, because the icons in git are current while the versioned theme releases are behind most of the time. ## FAQ ### What is MoreWaita and how does it relate to Adwaita? It is an expanded Adwaita-styled companion icon theme with extra icons for popular apps and MIME types, built largely on the work of GNOME's Adwaita designers and GNOME Circle app developers. The goal is to add to Adwaita rather than modify it, roughly what Breeze does for KDE, and it does not override any Adwaita icons, GNOME Circle app icons, or icons that fit the Adwaita paradigm. ### How do I install MoreWaita and what are the dependencies? The theme is built with Meson, with the build file at the root of the repository, and the repository includes an install.sh and a PACKAGING.md describing how to package it. The icon directories follow the standard theme layout with 16x16, scalable, and symbolic, and an index.theme file at the root makes the tree a theme the desktop can load. ### An icon is in MoreWaita but my application still shows the wrong one, what do I do? Open an issue and mention the icon name referenced in your application's `.desktop` file. Icon lookup matches by the name the desktop entry declares, so a mismatch between the theme's file name and the name in the desktop entry is why an icon in the theme can fail to apply. ### Why does MoreWaita keep brand colours in third-party app icons? It is a deliberate deviation. For most icons the goal is to stay as close to the original as possible while giving them the Adwaita perspective and general flatness, but one thing the theme deviates from is the Gnome colour palette in brand icons, because MoreWaita keeps the brand colours. ## Sources - [Issues](https://github.com/somepaulo/MoreWaita/issues) - [License: GPL-3.0](https://github.com/somepaulo/MoreWaita/blob/main/LICENSE) - [README](https://github.com/somepaulo/MoreWaita/blob/main/README.md) - [Releases](https://github.com/somepaulo/MoreWaita/releases) - [somepaulo/MoreWaita on GitHub](https://github.com/somepaulo/MoreWaita) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/somepaulo-morewaita