# Themix GUI and the plugin pipeline behind every exported theme

> Themix GUI is a Python colour editor that writes GTK2, GTK3, Cinnamon, GNOME, Openbox, Xfwm, icon and Base16 themes out of one palette. It earns a place on a Numix based Linux desktop and none at all on a stock one.

**themix-project/themix-gui** — Graphical application for generating different color variations of Oomox (Numix-based) theme (GTK2, GTK3, Cinnamon, GNOME, Openbox, Xfwm), Archdroid, Gnome-Color, Numix, Papirus and Suru++ icon themes. Have a hack for HiDPI in gtk2. Its Base16 plugin also allowing a lot of app themes support like Alacritty, Emacs, GTK4, KDE, VIM and many more.

- Repository: https://github.com/themix-project/themix-gui
- Stars: 2,324 · Forks: 74
- Language: Python
- License: GPL-3.0
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/themix-project-themix-gui

## One palette, six GTK and window manager targets

Themix GUI exists because a desktop theme is not one file. You choose a handful of colours once, and the project has to produce GTK2, GTK3, Cinnamon, GNOME, Openbox and Xfwm themes plus a matching icon theme, instead of leaving you to edit six unrelated trees by hand. On the icon side it covers Archdroid, Gnome-Color, Numix, Papirus, Suru++ and Suru++ Asprómauros, all derived from the same source colours as the GTK output. A Numix desktop looks unfinished when window decorations and file icons disagree about what blue means.

The audience is narrow, and saying so plainly saves an install. You need Linux, a Numix or Materia derived theme already in place, and enough patience to accept that the result is a set of generated directories rather than a patch against a source repository. Someone on a stock GNOME install has no matching asset tree to apply the output to. GTK2 support even carries a HiDPI hack, which tells you how much of the value sits in old toolkits rather than modern ones.

## Plugin modules own the export, not the window code

The repository layout states the architecture more plainly than any summary would. `oomox_gui/` holds the interface, `plugins/` holds the exporters, and the Makefile globs both when it assembles what it lints:
```makefile
TARGET_MODULE := oomox_gui
TARGETS := $(APP_DIR)/oomox_gui/ $(shell ls $(APP_DIR)/plugins/*/oomox_plugin.py) $(shell ls $(APP_DIR)/maintenance_scripts/*.py)
```
Every plugin file carries the same name, `oomox_plugin.py`, so the supported output formats are in practice the directory names under `plugins/`. Adding Base16 coverage meant adding a module rather than adding a flag to a dialog, and the same convention explains why an unsupported target cannot be coaxed in through settings. Translations travel with the application: the po/ and po.mk files sit at the top level beside `colors/`, `scripted_colors/` and `terminal_templates/`, all of which the installer copies as one block.

## Image, Xresources and Base16 are three different imports

Export plugins answer what happens to your colours; import plugins answer where they came from, and three routes are offered. One generates a palette from an image, one reads an existing scheme out of Xresources, and one draws on a large collection of Base16 schemes. That last route doubles as the bridge to everything that is not GTK, feeding Alacritty, Emacs, GTK4, KDE, Qt5ct, Qt6ct and VIM from a single 16 key scheme, with many more templates available upstream.

Read the page closely and the emphasis is telling. Exactly one screenshot is labelled as an import view, the image path, and no sample Xresources block appears anywhere in it. Base16 support is described as a side effect of a plugin rather than as a first class theme target, so a Qt or GTK4 user ends up expressing colour in Base16 naming instead of their toolkit's own vocabulary. Check what a given template produces before planning a migration onto it.

## Arch carries the install path, the Debian one is frozen

Install instructions are short here because most of the doors have been closed. On Arch a rolling package goes in with:
```bash
pikaur -S themix-full-git
```
Arch does not officially support AUR helpers, so that build can equally be compiled by hand from the rolling PKGBUILD, after which the GUI starts from a shell:
```bash
themix-gui
```
A Debian, Ubuntu and Linux Mint heading still exists, yet the text beneath it says the deb packages serve only older versions of Themix and points at issue 144 plus a page of old instructions. Everything else is routed to `docs_markdown/Manual_Installation.md`, with an invitation to build a package from the same information. That is a narrower support story than the theme lists advertise, and it belongs near the top of any rollout plan.

## The Makefile rewrites a hardcoded app path at build time

Packaging goes through one Makefile with three variables at the top:
```makefile
DESTDIR = ./distrib
PREFIX = /usr
APPDIR = /opt/oomox
```
The `install_gui` target depends on `install_import_random`, copies the application tree into `$(DEST_APPDIR)`, patches the shipped wrapper scripts, then installs three entry points at mode 755:
```bash
install -Dp -m 755 "$(PACKAGING_TMP_DIR)/packaging/bin/oomox-gui" -t "$(DEST_PREFIX)/bin/"
install -Dp -m 755 "$(PACKAGING_TMP_DIR)/packaging/bin/themix-gui" -t "$(DEST_PREFIX)/bin/"
install -Dp -m 755 "$(PACKAGING_TMP_DIR)/packaging/bin/themix-multi-export" -t "$(DEST_PREFIX)/bin/"
```
That substitution step is the part worth noticing: replacing `/opt/oomox/` with whatever `APPDIR` holds is what lets a distribution build install under a different prefix without touching sources. The same file resolves `python3` through `which` and aborts with a hard error when it is missing, so a broken interpreter fails the build rather than the first run. The code ships under GPL-3.0, and the installer copies `LICENSE` into the application directory beside `CREDITS`.

## Python 3.10 floor, strict mypy, three lint TODOs

Build metadata for a desktop utility is unusually exacting. pyproject.toml pins a distribution name that predates the rename and sets a language floor:
```toml
[project]
name = "oomox_gui"
version = "1.15.1"
requires-python = ">=3.10"
```
The mypy block switches on disallow_untyped_defs, disallow_any_generics, disallow_any_unimported, extra_checks and strict_equality, with hand written stubs under `maintenance_scripts/mypy_stubs`. The ruff block selects a wide set including ANN, S, BLE, TRY and D, yet three entries carry @TODO notes and stay commented out: FBT for boolean positional arguments, PTH for rewriting os.path with pathlib, T20 for turning print into logging. C901 also sits in the ignore list as too complex while mccabe caps complexity at 19, which leaves that gate inert.

One detail escapes a skim. The CI badge and every screenshot URL point at the sibling oomox repository, so the build status displayed on the page may come from a different pipeline than this code. The last push landed on 2026-09-08, and pyproject.toml still declares 1.15.1 with 2022-11-28 as the newest tag, so commits have arrived for years without a new version marker.

## Multi-export is the real alternative to the GUI

A second route runs through this codebase, and it is the one to pick for scripted builds. `docs_markdown/CLI.md` documents a command line path, `multi_export_cli.sh` sits at the top level, and the Makefile installs `themix-multi-export` next to the two GUI launchers. The installer also ships `export_config_examples/`, so theme definitions can live in configuration files and run as a batch.

The difference is concrete rather than cosmetic. The GUI is interactive: you adjust colours, watch a preview and export one scheme at a time. The batch path needs no display, which suits image builds or a palette change applied across several desktops, and it costs you the live preview that justified the graphical tool in the first place. Beyond GTK, the third option is editing a Base16 scheme directly, letting each application read the same file instead of maintaining per application colour definitions by hand.

## Colour choices land where no window ever previews them

Coverage is the real limitation, and it has two layers. The first is rendering. GTK2, GTK3, Cinnamon, GNOME, Openbox and Xfwm each interpret identical colour values differently, and the only HiDPI accommodation described is a hack for gtk2. A single export can write six theme directories that nothing has checked, so a contrast failure surfaces later, inside whichever application happens to draw the worst pairing.

The second layer is what stays undocumented. No page among the repository entries names the colour keys or the files they land in, and no rollback procedure is given if an export overwrites a theme you still wanted. A `dockerfiles/` directory and a `.dockerignore` sit in the tree while the install text never mentions containers or gives a build command, and the Flathub badge is commented out even though a `packaging/` directory still ships. The walkthrough videos linked from the page date from 2016 to 2019.

## Conclusion

Adopt Themix GUI if you already run a Numix or Materia derived Linux desktop and want a second accent palette without rebuilding theme assets by hand, because the plugin split lets one choice feed GTK, icon and Base16 targets together. Walk away if you sit on stock GNOME, if you need Debian packages, or if you were promised a container image. Before anything else, open the plugins/ directory and confirm a module exists for your toolkit, since output coverage is decided by which modules sit there and not by anything in the settings window.

## FAQ

### Which Linux distributions can I install Themix GUI on?

Arch is the documented path, through the rolling package `pikaur -S themix-full-git` or by compiling the PKGBUILD by hand, and the GUI is started with `themix-gui`. The Debian, Ubuntu and Linux Mint instructions only cover older versions of Themix, and every other distribution is pointed at `docs_markdown/Manual_Installation.md` to build a package itself.

### Does Themix GUI need a newer Python than my distribution ships?

pyproject.toml sets `requires-python = ">=3.10"`, so anything older is out. The Makefile also looks up python3 with which and stops with a Can't find error when it is absent, turning a missing interpreter into a build failure rather than a runtime surprise.

### Can Themix GUI export themes for applications that are not GTK, such as Alacritty or Emacs?

Yes, through the Base16 plugin, which covers Alacritty, Emacs, GTK4, KDE, Qt5ct, Qt6ct and VIM and can draw on many more upstream templates. Those targets come from the Base16 route rather than from dedicated per application plugins.

### Are Debian packages still available for Themix GUI?

Not as a current path. The Debian, Ubuntu and Linux Mint section states that this route works for installing older versions of Themix and refers to issue 144, with the rest of the documentation pushed to an old instructions page.

### Where does Themix GUI put its files, and can I move them?

The Makefile defaults to APPDIR `/opt/oomox` under PREFIX `/usr`, with DESTDIR at `./distrib`, and it substitutes that path inside the shipped wrapper scripts during install, so overriding APPDIR relocates the application. Three binaries, `oomox-gui`, `themix-gui` and `themix-multi-export`, are installed at mode 755 under the bin directory.

## Sources

- [Issues](https://github.com/themix-project/themix-gui/issues)
- [License: GPL-3.0](https://github.com/themix-project/themix-gui/blob/master/LICENSE)
- [README](https://github.com/themix-project/themix-gui/blob/master/README.md)
- [Releases](https://github.com/themix-project/themix-gui/releases)
- [themix-project/themix-gui on GitHub](https://github.com/themix-project/themix-gui)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/themix-project-themix-gui