gh0stzk/dotfiles: A BSPWM Environment With 18 Switchable Themes

What gh0stzk/dotfiles Actually Ships

This is not a set of shell aliases. It is a whole X11 desktop session: BSPWM as the window manager, polybar for the bar, rofi for launchers and applets, picom for compositing, dunst for notifications, eww for widgets, jgmenu for menus, and i3lock-color for the screen locker. The README describes the goal as a bspwm environment that is lightweight, efficient, and functional, tailored for any use, whether it is gaming, web browsing, or a productive work setting. The author is gh0stzk, and the repository is GPL-3.0 licensed.

The audience is narrow and specific. You need Arch Linux, a working X11 session, and a willingness to let someone else decide how your desktop behaves. The README points new users at a wiki page called First steps after installing the dotfiles, which is a fair signal that the install is not the end of the setup. If you already have a tuned BSPWM config, this repository will overwrite the parts of it that live in the same paths.

What separates it from a plain dotfiles repo is the theming layer. Eighteen themes ship with handcrafted palettes, and the README is explicit that colours are not extracted from wallpapers the way Matugen or Pywal do it. That is a design position, not a feature list.

How the Theming Pipeline Propagates One Palette

The mechanism the README describes is a modular theming system. Each theme carries a colour palette, and switching themes pushes those values into every module that has been enabled. The list of targets is long: BSPWM itself, GTK 3.x, Dunst, Rofi, five terminals (Alacritty, Ghostty, Kitty, St and Xfce-terminal), Neovim, Eww, Firefox, Jgmenu, Geany, the i3lock-color screen locker, Mpv, Cava, Zathura, Polybar, and a set of CLI tools including Yazi, Fzf-Tab, Bat, Eza and Ncmpcpp.

The README adds a qualifier that matters more than the list: not all modules are enabled. A separate wiki page, Color Modules, documents how to turn them on or off. So the honest reading is that the pipeline can reach all of those programs, but a fresh install will not necessarily recolour every one of them, and you have to go read the module documentation to know which ones are live.

Because the palettes are handcrafted rather than sampled from an image, switching a wallpaper does not change your accent colour. The trade-off is the reverse of the Pywal model: you get predictable contrast and readability across themes, but you lose the automatic match between a new wallpaper and the rest of the desktop. If you change wallpapers often and want the UI to follow, this is the wrong tool.

The theme switch itself is described as instant, with no session or environment restart. That is the headline behaviour, and it is the reason the theming is structured as modules rather than as a set of static config files you edit by hand.

Installing gh0stzk/dotfiles With RiceInstaller

The repository root holds a directory named RiceInstaller alongside config/, home/ and misc/. The README links an Install section but the cleaned text does not reproduce the exact command line, so the reliable path is to clone the repository and run the installer script from the checkout rather than guessing flags. The README does not document rollback, so take a backup of your existing ~/.config before you start.

A typical sequence looks like this. The clone puts the tree on disk, and the installer is the entry point the repository layout advertises.

git clone https://github.com/gh0stzk/dotfiles.git
cd dotfiles
ls RiceInstaller

After the installer runs, the README directs you to the wiki page First steps after installing the dotfiles before you start customising. Treat that as part of the install, not optional reading.

The first real interaction after a session restart is the theme selector. The README describes switching themes with one click and no session restart. Keybindings are documented on a wiki page called Keyboard Shortcuts rather than in the README body, so check there for the binding that opens the selector on your install.

Multi-monitor handling is automatic for up to four displays at launch. If you plug in a monitor while the session is running, the README says to reload BSPWM with Super + Alt + r and the displays are configured. That keybinding is the one concrete shortcut the README states outright.

Wallpapers are configured per theme, and the README lists five engines: Random, CustomDir, Default, CustomAnimated for .mp4, .mkv and .gif files, and Slideshow, which rotates a random image from the theme's Walls directory every 15 minutes. Each theme keeps its own choice, so one theme can run an animated wallpaper while another stays static.

Where the Design Costs You Something

The theming model is the biggest constraint. Handcrafted palettes mean the colour set is fixed. If a theme's accent clashes with a wallpaper you like, your options are to pick a different wallpaper or edit the theme by hand. There is no extraction step to fall back on.

The second constraint is the module list. Because not all modules are enabled by default, a user who installs and then wonders why Bat or Ncmpcpp still shows the old colours will find the answer only on the Color Modules wiki page. The README states the fact but does not enumerate which modules are on, which is a documentation gap a new user will hit in the first hour.

The third is the platform. Everything here assumes X11: BSPWM, picom, i3lock-color and polybar are X11 tools. The repository's topic list includes hyprland, but the README describes a BSPWM environment, and the installer and config tree are built around that. Do not read the hyprland topic as a Wayland port.

The performance claim in the README is the author's own measurement on his systems: under 600 MB of RAM at start. That number is not reproducible from the repository alone, and the README itself hedges by saying these numbers do not tell the whole story. Treat it as an order of magnitude, not a benchmark.

Finally, the README's ToDo-List names Obsidian, Telegram-desktop, Steam, Btop, Qt 5/6 and Rmpc as theming targets that are not done. If one of those is central to your workflow, the theme switch will not reach it.

RiceEditor and the Per-Theme Configuration Model

Each theme can be configured independently, either by editing the theme's configuration file directly or through an application called RiceEditor, which the README describes as a tool to adjust visual and configuration aspects without manually editing files. The adjustable items named in the README are animations, shadows, rounded borders and fading effects. That is a small surface, and it is deliberate: the point is per-theme granularity, so a minimalist theme can run with everything off while another keeps the eye candy.

This is where the repository differs from a single global config with a colour variable. Settings are preserved per theme. Switch from a heavy theme to a light one and back, and the README's model says your choices come back with it. The cost is duplication: eighteen themes means eighteen places where a setting can live, and the RiceEditor exists precisely because editing them by hand is tedious.

The wallpapers follow the same pattern. Random, CustomDir, Default, CustomAnimated and Slideshow are chosen per theme, and the README says the default is a static image from the theme's Walls Rice folder. The Slideshow engine's 15-minute interval is fixed in the documentation as written; there is no stated option to change it in the README.

Rofi Applets, Scratchpad and the Neovim Config

The bundled rofi applets cover wallpaper selection, network management, Bluetooth, clipboard history, screenshots, Android MTP, power menu, keyboard layout, terminal selection among Alacritty, Kitty, St and Ghostty, a rofi launcher style selector, a tab app switcher and a pass-based password manager. Each has its own wiki page where the README links one, the WallpaperSelector. The practical effect is that you get a menu layer without writing rofi scripts yourself, but you also inherit someone else's choices about which applets exist and how they are bound.

The scratchpad is a floating, toggleable surface for a terminal, editor or notes. The README describes it as appearing over the current workspace and staying alive in the background when hidden. Nothing exotic, but it is the kind of thing that is annoying to build from scratch and easy to take for granted once present.

The Neovim configuration is separate from the theming story and is described as simple yet powerful: Treesitter, LSP servers, blink.nvim for completions, conform.nvim for formatting, Snacks-picker for picking, Snacks-explorer for file browsing, and barbar.nvim for the tab line. Note that the README's Neovim section is truncated mid-sentence in the repository text, so the full plugin list should be checked in config/ rather than assumed from the README. If you already have a Neovim setup you like, expect a conflict.

Alternatives and When gh0stzk/dotfiles Is the Wrong Choice

The obvious comparison is a wallpaper-derived theming stack. Matugen and Pywal, both named in the README, sample colours from an image and generate palettes from them. gh0stzk/dotfiles does the opposite: fixed palettes, chosen by hand, propagated to modules. If your priority is that the desktop always matches the current wallpaper, Pywal-style tooling is the better fit and this repository is not. If your priority is that contrast and readability stay constant no matter what image you set, the handcrafted approach is the reason to pick this one.

The second comparison is a Wayland compositor setup. Hyprland rices, including the ones that show up under the dotfiles hyprland search term, target Wayland and typically pair with Waybar, wofi or rofi-wayland, and a Wayland-native locker. gh0stzk/dotfiles is X11: BSPWM, polybar, picom, i3lock-color. That difference decides the choice before any aesthetic question does.

The third is a stow-managed dotfiles repo. A plain dotfiles repository managed with GNU Stow gives you symlinks and no installer, no theme engine and no opinion about your bar. gh0stzk/dotfiles gives you the opposite: a RiceInstaller that copies a working environment into place. If you want to keep your own configs and cherry-pick, a stow layout is easier to reason about. If you want a complete desktop in one step, the installer is the point.

Where this is clearly wrong: non-Arch distributions, Wayland sessions, machines where you cannot afford a full config overwrite, and anyone who wants the desktop to follow the wallpaper automatically.

Editorial conclusion

Use gh0stzk/dotfiles if you run Arch Linux on X11 and want a complete BSPWM rice with 18 themes you can switch live, rather than assembling polybar, rofi, picom and dunst yourself. Do not use it if you are on Wayland, on a non-Arch distribution, or if you want to keep your existing dotfiles, because the installer writes into config/ and home/ paths and the README documents no rollback. Before running anything, read the wiki pages First steps after installing the dotfiles and Questions - Answers, and check the CHANGELOG.md for what the last push on 2026-08-24 changed.

Frequently asked questions

Official sources

1. gh0stzk/dotfiles on GitHub
2. Issues
3. License: GPL-3.0
4. README