zenities: a Hyprland rice for Arch, installed by a shell script

A desktop configuration, not an application

zenities is described as a Hyprland custom configuration. The repository description is a single line: a Hyprland custom configuration, and the primary language is Shell.

That framing sets expectations correctly. This is not a program with a user interface and a feature list. It is a set of configuration files, scripts and assets that together make up a working desktop environment, in the tradition the community calls a rice. The README is upfront about the provenance: the author is relatively new to ricing, the result is nowhere near perfect, and the configuration is inspired by a great many other people's work that cannot all be listed.

The scope is a complete desktop. The Details section names the operating system as Arch Linux, the desktop environment as Hyprland, the terminal as Kitty, the music player as ncspot, the shell as zsh, the bar as eww, the application launcher as Rofi, the editor as Neovim and the file manager as yazi. Colours are generated with pywal from the wallpaper, so the scheme follows the background.

The intended user is therefore quite specific: an Arch user who has chosen the Hyprland Wayland compositor, wants a keyboard-driven desktop, and is willing to adopt somebody else's decisions about their keymap. What they get in exchange for that is a working configuration in one sitting rather than a weekend of assembling one.

The installer writes into your home directory

Installation is a shell script, and the requirements are stated bluntly: this installation script only works on Arch Linux and requires Hyprland to be installed.

The sequence is short. You install Git with pacman, clone the repository into your home directory with a shallow clone, change into it and run the script:

sudo pacman -S git

cd $HOME
git clone --depth 1 https://github.com/hayyaoe/zenities

cd zenities

sh INSTALL.sh

The top level entries explain what the script is doing. There is a .config/ directory, which is the conventional location for application configuration under the XDG scheme, a .local/ directory for user-local files, scripts/ for the helper programs bound to the keybinds, wallpapers/ for the backgrounds, and screenshots/ for the README images. There is also a .templates/ directory, a .tmux.conf, a .p10k.zsh for the Powerlevel10k shell prompt, and a .stow-local-ignore.

That last file points at the mechanism. The presence of GNU Stow ignore rules, together with UNINSTALL.sh next to INSTALL.sh, says the configuration is managed with GNU Stow, the tool that symlinks a directory of files into your home directory. With Stow, the configuration lives in one place and is linked into place, so removing the links is a clean operation rather than a search for stray files.

Turning off autogeneration is the step that decides everything

Before the install, the README has a prerequisite section with a single requirement: you have to disable autogenerate on the hyprland.conf.

The steps are explicit. You change to the Hyprland configuration directory, edit the file with a text editor, find the line or section that enables autogeneration, which may look like this:

autogenerated=1

and you disable it by setting the value to 0 or commenting the line out:

# autogenerated=1

Then you save, exit, and reload Hyprland:

hyprctl reload

Finally you verify that the settings are no longer being autogenerated by checking that your custom configuration persists after a restart.

Why this matters is worth stating plainly. Hyprland generates a hyprland.conf from its own settings, and if autogeneration is left on, the file is rewritten from that source on every start. Any manual edit, including the entire configuration this repository installs, is then discarded. A user who installs first and reads the prerequisite afterwards will conclude the rice does not work, when in fact the compositor overwrote it.

The README's phrasing on the check is also the honest way to verify it: not by reading the file once, but by restarting and confirming the configuration is still there.

The keymap is documented in full

The README devotes more space to keybinds than to anything else, which is right for a configuration whose value is in the ergonomics.

Application launching uses the SUPER key throughout: SUPER and RETURN opens a tiled terminal running tmux, SUPER with SHIFT and RETURN opens a floating terminal, SUPER and M launches Yazi through a custom script, SUPER with SHIFT and M opens Yazi floating, SUPER and B opens the default browser, and SUPER and SPACE opens the application menu, bound to $menu.

System scripts cover wallpaper reload with SUPER and A, a power menu with SUPER and P, a wallpaper selector with SUPER with SHIFT and W, widgets with SUPER and H running the Eww or custom widget script, and a Waybar reload with SUPER and R.

Window management is where the layout logic lives. SUPER and Q kills the focused window, SUPER and V toggles floating, SUPER and J toggles the split orientation between vertical and horizontal, and SUPER and F toggles fullscreen. Focus moves with ALT and H, L, K and J for left, right, up and down. Tiled windows move with ALT and SHIFT and the same four keys. Tiled windows resize with SUPER and ALT and H, L, K and J. Floating windows move with SUPER and CTRL and the same four keys.

The Notes section explains the reasoning: most of the keybinds are designed with colemak as the default layout so feel free to customize, SUPER usually refers to the Windows or Command key, and the bindings follow an HJKL, left-down-up-right, layout inspired by VIM-style ergonomics for faster directional control. It closes by saying you can customize these further to suit your workflow or preferred keyboard layout.

What the scripts and widgets actually do

The keybind table names the scripts without describing them, so the details section carries the load. The bar is eww, and the screenshots show a tmux session alongside ncspot and cava, plus a separate screenshot of the wallpaper switcher, the Neovim configuration and the main desktop.

The wallpaper is more than decoration here. The README states that the rice used pywal to create custom colourschemes depending on the wallpaper used, which is why there is both a wallpaper selector script bound to SUPER with SHIFT and W and a wallpaper reload bound to SUPER and A. The reload one exists because the colour scheme is derived from the image: change the image and the colours change, so the bar and any other pywal-aware component have to be told to re-read the generated scheme. The widget script bound to SUPER and H and the Waybar reload bound to SUPER and R are the other half of that loop.

The terminal side uses tmux, and the SUPER and RETURN binding deliberately launches a tiled terminal with tmux rather than a plain shell. That makes tmux the session manager for every terminal window, which is what allows a session to survive closing and reopening a terminal in a tiling window manager.

The file manager is Yazi, launched through a custom script rather than directly, with both a tiled and a floating binding, and the editor is Neovim. The screenshots directory carries four images, which is a fair indication of how much of this configuration is visible in text.

No licence, no releases, and an explicit work in progress

The licence field on the repository is empty, GitHub reports the licence as unknown, and there is no licence file among the top level entries, which are .config/, .github/, .gitignore, .local/, .p10k.zsh, .stow-local-ignore, .templates/, .tmux.conf, INSTALL.sh, README.md, UNINSTALL.sh, screenshots/, scripts/ and wallpapers/.

That is worth pausing on for a configuration people are invited to copy. The README says feel free to use this rice, and the author asks for no attribution beyond the credits section. But without a licence file, the default position under copyright is that nobody else may copy, modify or redistribute it. For a personal desktop configuration that most people will never publish, that is a theoretical problem. For anyone who wants to fork it, publish a variant, or base a dotfiles repository on it, it is a real one, and the fix is a question to the author.

The rest of the state is straightforward. The repository is not archived, the last push was on 2026-10-17, and there are no GitHub releases, so there is no tagged version to point at and no changelog to diff. The README points to the repository issues page for more details or issues.

The credits name Rxyhn, saimoomedits and Vimjoyer, and the star history chart is embedded at the bottom. The author's own framing is the fairest summary available: relatively new to ricing, nowhere near perfect, and put together with a lot of care. An evaluator should take that literally. Expect a configuration that works, that is opinionated, and that will need adjusting.

Editorial conclusion

zenities suits an Arch Linux user who has decided on Hyprland, wants a complete working desktop rather than a menu of options, and is comfortable overwriting their existing configuration with a shell script. It does not suit a user on any distribution other than Arch, because the installer states it only works there, and it does not suit someone who needs to reuse the configuration under a different licence or with their own hyprland.conf kept intact. Before installing, read INSTALL.sh and UNINSTALL.sh, commit or back up your existing ~/.config/hypr, and turn off autogeneration in hyprland.conf as the README describes, since that is the step that decides whether the configuration survives a restart.

Frequently asked questions

Official sources

1. hayyaoe/zenities on GitHub
2. Issues
3. README