endeavouros-i3wm-setup: the default i3 configuration shipped with EndeavourOS

What this repository is, and who maintains it

This is the EndeavourOS default i3 theme and setup dotfile repository, and the readme describes it as the beloved EndeavourOS default i3 theme, with the note that it has gaps.

The summary is short: dotfiles for i3 window manager under EndeavourOS, maintained by killajoe, Joe Kamprad, with details about enhancements and changes on his blog at kamprad.net.

The interesting thing about a dotfile repository of this kind is what it actually is. It is not a theme in the sense of a colour scheme alone. It is a complete desktop arrangement: the window manager configuration, a status panel, a launcher, a notification daemon, a wallpaper setter, a file browser, a text editor, a terminal, a screen locker, and the theme files that tie them together. The readme calls it the default i3 theme, but reading the sections below shows it is closer to a curated desktop.

That framing also tells you what to expect from adopting it. You are not picking up a few colour definitions and adjusting them; you are adopting somebody's arrangement of a dozen applications, with the paths and defaults that arrangement implies. Some of those choices are configurable, some are hardcoded in scripts, and the readme points at specific files for most of them.

The primary language is Shell, the licence is GPL-3.0, the default branch is main, and the last push was on 2026-05-16. The repository has no GitHub releases and no homepage of its own.

The top-level entries show the shape of the thing: an etc/ directory holding the configuration files, a LICENSE, a README.md, a force-knowledge.md, two scripts named i3_install and i3_install_isomode, and a packages-repository.txt. The two install scripts are the mechanism for applying the setup, and the packages file is presumably the list of dependencies the setup expects to be present.

The default applications, and the configuration paths

The settings tutorial lists the applications the setup expects, and for each one names the file that controls it. That mapping is the most useful part of the readme, because it tells you where to look when something is not what you want.

The background wallpaper is feh. The file browser is thunar. GTK theming uses nwg-look, with the configuration spread across the gtk-3.0 and gtk-4.0 directories, the .gtkrc-2.0 file and an nwg-look gsettings directory under .local/share.

The terminal emulator is xfce4-terminal, and the readme calls out an important detail about it. It is also set inside .profile as export TERMINAL=xfce4-terminal, so if you want to change the default terminal you need to change it in .profile as well. That is the kind of duplication that catches people out, because the i3 config alone is not enough.

The text editor is xed, configured through xed.dconf, and to reset the default settings the readme gives the command to run.

XDG autostart is handled by dex, which starts applications from /etc/xdg/autostart/ the way a desktop environment would. Dex is enabled by default in the i3 config, and to disable it you comment out the line exec --no-startup-id dex --autostart --environment i3 in the i3 config.

Notifications come from dunst, configured in the dunstrc file under the dunst config directory. The application launcher is rofi, configured in the rofi config directory, and rofi is used for more than launching: the logout menu and the application menu both use it.

So the dependency set is a specific one: feh, thunar, nwg-look, xfce4-terminal, xed, dex, dunst and rofi, plus xss-lock and blur-lock for the screen locker and the powerprofilesctl utility for the power profile menu. Anyone adopting this on a system without those installed will find the configuration referring to commands that do not exist.

The i3 config, key bindings and the tiling modes

The window manager configuration itself lives in the i3 config file, and the keybindings differ from the i3 defaults to fit the setup.

The mod key is set to the Windows/Super key, and the readme says there are two methods to view the default key bindings. Method 1 is that the keyboard icon on the panel opens a small GUI helper, and method 2 is pressing F1.

That helper is a nice touch and worth calling out, because the usual complaint about a distributed i3 configuration is that you cannot find out what the keys are without reading the config file. A panel icon that lists them, or an F1 binding that shows them, removes the discovery problem entirely.

On tiling, the setup is left at the i3 default, and the readme explains the two modes it refers to. Stacking mode displays only the focused window in the container, and you get a list of windows at the top of the container. Tabbed mode opens each new window in fullscreen as a tab, and you move between window tabs with the mouse or a shortcut, with mod plus Left focusing left and mod plus Right focusing right.

The screen locker is the next piece, and it uses two tools for two different situations. blur-lock and xss-lock are used, and the config is in ~/.config/i3/config.

# lock by blurring the screen:
bindsym $mod+l exec --no-startup-id ~/.config/i3/scripts/blur-lock
# lock in case after sleep
exec --no-startup-id xss-lock --transfer-sleep-lock -- "~/.config/i3/scripts/blur-lock"

The distinction is worth understanding. The manual binding blurs the screen, which is the lighter-weight option, while the sleep case hands the lock over to xss-lock, which takes over the session lock when the machine suspends. The transfer-sleep-lock flag on xss-lock is what passes control to it at that point, and the command it runs is the same blur-lock script.

So a sleep will lock the screen even if you never pressed the key combination, which is the behaviour most people want and which a bare blur-lock setup does not give you.

Displays, the panel and the scripts behind it

The display setup is the part of the readme with the most moving pieces, and it is worth reading before you install anything.

The process is described as a sequence. Open arandr and set up the displays as you need them. Save the setup from the arandr menu or button exactly with the filename monitor. And in the i3 EndeavourOS configuration there is a starter line that starts a script to set up the displays.

  # start a script to setup displays
  # put `monitor.sh` into the location specified by this line
  exec --no-startup-id "${HOME}"/.screenlayout/monitor.sh

So the arrangement is: arandr writes a layout file named monitor, that file goes into a directory called .screenlayout in your home directory, the monitor.sh script goes in the same place, and the i3 config runs it at login. The readme notes this handles setting the display on each login, and that you could alternatively write your own script with xrandr.

The requirement that the filename be exactly monitor is the sort of detail that looks trivial and then wastes an evening when the layout file is called monitor.yaml and nothing happens on login.

The panel bar uses i3blocks, and the readme lists what it gives you: workspaces, the active i3 blocks, tray icons and the ability to launch applications. The config is in the i3blocks.conf file in the i3 config directory.

The blocks themselves cover PulseAudio, where the mouse wheel over the volume level adjusts it and a right click opens the PulseAudio control; weather, which needs an API key from OpenWeatherMap and a city code, where the city code is the seven numbers at the end of the URL after you search your city on the OpenWeatherMap find page, and both go into the openweather.sh script in the i3 scripts directory; tray icons for things like the network manager and an update indicator; and a logout button offering Cancel, Lock, Logout, Reboot, Shutdown and Suspend.

The logout menu is built with rofi and configured in the powermenu script, and the application menu is rofi too, letting you launch apps, run commands and switch windows.

The power profiles handler menu uses powerprofilesctl to switch power modes from the panel bar.

The readme closes the details section by pointing at where to find the examples: scripts under $HOME/.config/i3/scripts/ and blocks under $HOME/.config/i3/i3blocks.conf, and it tells you to run the openweather script with the -s flag to create the setup you will need.

The theming, and what the rasi files control

The colour scheme is split across several files, and the readme names each one.

The rofi application menu and the logout menu have their own theme files, rofidmenu.rasi for the application menu and powermenu.rasi for the logout menu. The rofi colour schemes are separate, arc_dark_transparent_colors.rasi and arc_dark_colors-ori.rasi. The readme notes that the colours are in RGBA, with transparency given in the last column, in the form rgba ( 26, 28, 35, 100 % ).

That transparency column is worth noting because it is what makes a translucent panel and menu possible, and because the format is the kind of thing that trips people up when they edit the file by hand and the menu renders with a solid background.

GTK3 theming and icons live in the gtk-3.0 config directory and in the .Xresources file, with nwg-look installed so you can browse and set the GTK theme, the icons and the Xcursor theme.

The Xcursor part has a sizing constraint that the readme calls out. Xcursor needs .Xresources set in cases to have the right size in all cases, which is a reminder that the cursor theme is scaled from configuration rather than being fixed.

The GTK4 piece is the recent addition and it is handled differently, because some applications have moved to GTK4. You add a settings.ini file in the gtk-4.0 config directory with only the theme lines.

[Settings]
gtk-theme-name=Arc-Dark

With that, GTK4 applications follow the theme, and the readme notes it will be needed to change manually on theme changes. That last caveat is the important one: the GTK3 side picks up theme changes through nwg-look and the Xresources file, but the GTK4 side reads a static settings.ini, so a theme change has to be applied there too.

So the theming is a mix of mechanisms: rasi files for rofi, Xresources for GTK3 and the cursor, and a separate ini file for GTK4. It is not unified, and that is why the readme is explicit about each part.

Editorial conclusion

endeavouros-i3wm-setup fits an EndeavourOS user who installed the distribution's i3 option and wants the maintained configuration rather than their own, and it does not fit someone on another distribution, since the setup assumes EndeavourOS packages and the paths the distribution installs. Before switching to it, read the display setup section, because the arrangement depends on an arandr layout saved under the filename monitor and a monitor.sh script that the i3 config expects at a specific path in your home directory.

Frequently asked questions

Official sources

1. endeavouros-team/endeavouros-i3wm-setup on GitHub
2. Issues
3. License: GPL-3.0
4. README