Top Related Projects
A tiling window manager for X11
A manual tiling window manager for X11
awesome window manager
:cookie: A full-featured, hackable tiling window manager written and configured in Python (X11 + Wayland)
The core of xmonad, a small but functional ICCCM-compliant tiling window manager
i3-compatible Wayland compositor
Quick Overview
BSPWM (Binary Space Partitioning Window Manager) is a tiling window manager for X11. It represents windows as the leaves of a full binary tree, allowing for efficient and flexible window management. BSPWM is designed to be lightweight, customizable, and scriptable.
Pros
- Highly customizable and configurable
- Efficient use of screen space through tiling
- Scriptable with simple shell commands
- Supports multiple monitors seamlessly
Cons
- Steep learning curve for new users
- Requires manual configuration and setup
- Limited built-in features compared to full desktop environments
- May not be suitable for users who prefer traditional stacking window managers
Getting Started
To get started with BSPWM, follow these steps:
-
Install BSPWM and its dependencies:
# For Debian/Ubuntu sudo apt install bspwm sxhkd -
Create configuration directories:
mkdir -p ~/.config/{bspwm,sxhkd} -
Copy example configuration files:
cp /usr/share/doc/bspwm/examples/bspwmrc ~/.config/bspwm/ cp /usr/share/doc/bspwm/examples/sxhkdrc ~/.config/sxhkd/ -
Make the bspwmrc file executable:
chmod +x ~/.config/bspwm/bspwmrc -
Edit the configuration files to customize your setup:
nano ~/.config/bspwm/bspwmrc nano ~/.config/sxhkd/sxhkdrc -
Start BSPWM by adding the following line to your ~/.xinitrc file:
exec bspwm -
Log out and log back in, selecting BSPWM as your window manager.
Remember to configure sxhkd for keyboard shortcuts and consider using a status bar like polybar for a complete setup.
Competitor Comparisons
A tiling window manager for X11
Pros of i3
- More feature-rich and user-friendly configuration
- Better documentation and larger community support
- Supports both tiling and floating window management
Cons of i3
- Less flexible layout management compared to manual tiling
- Heavier resource usage, especially with many windows open
- Steeper learning curve for advanced customization
Code Comparison
i3 configuration example:
bar {
status_command i3status
position top
}
bindsym $mod+Return exec i3-sensible-terminal
bindsym $mod+Shift+q kill
bspwm configuration example:
bspc config border_width 2
bspc config window_gap 12
bspc rule -a Gimp desktop='^8' state=floating follow=on
bspc rule -a Firefox desktop='^2'
i3 uses a more structured configuration file with specific keywords, while bspwm relies on shell commands for configuration. i3's approach may be more intuitive for beginners, but bspwm's method offers more flexibility for advanced users.
Both window managers are highly customizable, but they differ in their approach to layout management and configuration. i3 provides a more comprehensive out-of-the-box experience, while bspwm offers greater flexibility for users who prefer manual control over their window layouts.
A manual tiling window manager for X11
Pros of herbstluftwm
- More flexible and customizable tiling layouts
- Easier to configure with simple text-based configuration
- Better support for multi-monitor setups
Cons of herbstluftwm
- Steeper learning curve for new users
- Less active development and smaller community
- Fewer built-in features, requiring more manual configuration
Code Comparison
herbstluftwm configuration example:
hc keybind $Mod-Shift-q quit
hc keybind $Mod-Shift-r reload
hc keybind $Mod-w close
hc keybind $Mod-Return spawn ${TERMINAL:-xterm}
bspwm configuration example:
bspc rule -a Gimp desktop='^8' state=floating follow=on
bspc rule -a Chromium desktop='^2'
bspc rule -a mplayer2 state=floating
bspc rule -a Kupfer.py focus=on
Both window managers use simple configuration files, but herbstluftwm's approach is more human-readable and easier to understand for beginners. bspwm's configuration tends to be more concise and uses a specific syntax for defining rules and behaviors.
herbstluftwm offers more flexibility in creating custom layouts and arranging windows, while bspwm focuses on providing a binary space partitioning system with a simpler set of rules. The choice between the two often comes down to personal preference and specific workflow requirements.
awesome window manager
Pros of awesome
- Highly customizable with Lua scripting
- Built-in widgets and layouts
- Active community and extensive documentation
Cons of awesome
- Steeper learning curve due to Lua configuration
- Can be resource-intensive with complex configurations
- Less focus on tiling compared to pure tiling WMs
Code comparison
awesome (rc.lua):
awful.layout.layouts = {
awful.layout.suit.floating,
awful.layout.suit.tile,
awful.layout.suit.tile.left,
awful.layout.suit.tile.bottom,
awful.layout.suit.tile.top,
}
bspwm (bspwmrc):
bspc config border_width 2
bspc config window_gap 12
bspc config split_ratio 0.52
bspc config borderless_monocle true
bspc config gapless_monocle true
Key differences
- awesome uses Lua for configuration, while bspwm uses shell scripts
- awesome provides a full window manager framework, whereas bspwm focuses solely on tiling
- bspwm has a simpler configuration but requires external programs for some functionality
- awesome offers more built-in features and widgets out of the box
- bspwm generally has lower resource usage and a smaller codebase
Both window managers are highly regarded in the Linux community, with awesome offering more features and customization options, while bspwm provides a lightweight and focused tiling experience.
:cookie: A full-featured, hackable tiling window manager written and configured in Python (X11 + Wayland)
Pros of qtile
- Written in Python, making it highly customizable and easier for many users to configure
- Includes a built-in status bar and widget system
- Supports both tiling and floating window management out of the box
Cons of qtile
- Generally consumes more system resources due to being Python-based
- May have a steeper learning curve for users unfamiliar with Python
- Less minimalistic compared to bspwm, which might not suit all users' preferences
Code Comparison
qtile configuration example:
from libqtile import bar, layout, widget
from libqtile.config import Key, Group, Drag, Click
from libqtile.lazy import lazy
keys = [
Key(["mod1"], "k", lazy.layout.down()),
Key(["mod1"], "j", lazy.layout.up()),
]
bspwm configuration example:
#! /bin/sh
bspc config border_width 2
bspc config window_gap 12
bspc config split_ratio 0.52
bspc config borderless_monocle true
Both window managers offer extensive customization options, but qtile's Python-based configuration allows for more complex logic and integrations. bspwm's configuration is simpler and more lightweight, focusing on core window management features.
The core of xmonad, a small but functional ICCCM-compliant tiling window manager
Pros of xmonad
- Written in Haskell, offering strong type safety and functional programming benefits
- Highly extensible and customizable through Haskell scripting
- Large and active community with extensive documentation and plugins
Cons of xmonad
- Steeper learning curve due to Haskell configuration
- Potentially higher resource usage compared to C-based window managers
- Less intuitive for users unfamiliar with functional programming concepts
Code Comparison
xmonad (Haskell):
main = xmonad $ def
{ modMask = mod4Mask
, layoutHook = Tall 1 (3/100) (1/2) ||| Full
, terminal = "xterm"
}
bspwm (Shell script):
bspc config border_width 2
bspc config window_gap 12
bspc config split_ratio 0.52
bspc config borderless_monocle true
bspc config gapless_monocle true
xmonad configuration is done in Haskell, allowing for more complex and powerful customizations, while bspwm uses shell scripts for configuration, which may be more familiar to some users but potentially less flexible for advanced setups.
i3-compatible Wayland compositor
Pros of Sway
- Native Wayland support, offering better performance and security
- More modern codebase with active development and frequent updates
- Built-in support for HiDPI displays and multi-monitor setups
Cons of Sway
- Limited compatibility with X11 applications compared to BSPWM
- Steeper learning curve for users transitioning from X11 environments
- Fewer third-party tools and scripts available due to its newer ecosystem
Code Comparison
BSPWM configuration example:
bspc config border_width 2
bspc config window_gap 12
bspc config split_ratio 0.52
bspc config borderless_monocle true
bspc config gapless_monocle true
Sway configuration example:
default_border pixel 2
gaps inner 12
default_orientation auto
workspace_layout default
Both window managers use configuration files to define behavior, but Sway's syntax is more similar to i3, while BSPWM uses its own unique syntax. Sway offers more built-in options for customization, whereas BSPWM relies more on external scripts for advanced functionality.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Description
bspwm is a tiling window manager that represents windows as the leaves of a full binary tree.
It only responds to X events, and the messages it receives on a dedicated socket.
bspc is a program that writes messages on bspwm's socket.
bspwm doesn't handle any keyboard or pointer inputs: a third party program (e.g. sxhkd) is needed in order to translate keyboard and pointer events to bspc invocations.
The outlined architecture is the following:
PROCESS SOCKET
sxhkd --------> bspc <------> bspwm
Configuration
The default configuration file is $XDG_CONFIG_HOME/bspwm/bspwmrc: this is simply a shell script that calls bspc.
An argument is passed to that script to indicate whether is was executed after a restart ($1 -gt 0) or not ($1 -eq 0).
Keyboard and pointer bindings are defined with sxhkd.
Example configuration files can be found in the examples directory.
Monitors, desktops and windows
bspwm holds a list of monitors.
A monitor is just a rectangle that contains desktops.
A desktop is just a pointer to a tree.
Monitors only show the tree of one desktop at a time (their focused desktop).
The tree is a partition of a monitor's rectangle into smaller rectangular regions.
Each node in a tree either has zero or two children.
Each internal node is responsible for splitting a rectangle in half.
A split is defined by two parameters: the type (horizontal or vertical) and the ratio (a real number r such that 0 < r < 1).
Each leaf node holds exactly one window.
Insertion modes
When bspwm receives a new window, it inserts it into a window tree at the specified insertion point (a leaf) using the insertion mode specified for that insertion point.
The insertion mode tells bspwm how it should alter the tree in order to insert new windows on a given insertion point.
By default the insertion point is the focused window and its insertion mode is automatic.
Manual mode
The user can specify a region in the insertion point where the next new window should appear by sending a node -p|--presel-dir DIR message to bspwm.
The DIR argument allows to specify how the insertion point should be split (horizontally or vertically) and if the new window should be the first or the second child of the new internal node (the insertion point will become its brother).
After doing so the insertion point goes into manual mode.
Let's consider the following scenario:
a a a
/ \ / \ / \
1 b ---> c b ---> c b
^ / \ / \ / \ / \ / \
2 3 4 1 2 3 d 1 2 3
^ / \
5 4
^
+-----------------------+ +-----------------------+ +-----------------------+
| | | | | | | | | |
| | 2 | | 4 | 2 | | 5 | 4 | 2 |
| | | | ^ | | | ^ | | |
| 1 |-----------| |-----------|-----------| |-----------|-----------|
| ^ | | | | | | | |
| | 3 | | 1 | 3 | | 1 | 3 |
| | | | | | | | |
+-----------------------+ +-----------------------+ +-----------------------+
X Y Z
In state X, the insertion point is 1.
We send the following message to bspwm: node -p north.
Then add a new window: 4, this leads to state Y: the new internal node, c becomes a's first child.
Finally we send another message: node -p west and add window 5.
The ratio of the preselection (that ends up being the ratio of the split of the new internal node) can be changed with the node -o|--presel-ratio message.
Automatic mode
The automatic mode, as opposed to the manual mode, doesn't require any user choice. The way the new window is inserted is determined by the value of the automatic scheme and the initial polarity settings.
Longest side scheme
When the value of the automatic scheme is longest_side, the window will be attached as if the insertion point was in manual mode and the split direction was chosen based on the dimensions of the tiling rectangle and the initial polarity.
Let's consider the following scenario, where the initial polarity is set to second_child:
1 a a
^ / \ / \
---> 1 2 ---> 1 b
^ / \
2 3
^
+-----------------------+ +-----------------------+ +-----------------------+
| | | | | | | |
| | | | | | | 2 |
| | | | | | | |
| 1 | | 1 | 2 | | 1 |-----------|
| ^ | | | ^ | | | |
| | | | | | | 3 |
| | | | | | | ^ |
+-----------------------+ +-----------------------+ +-----------------------+
X Y Z
In state X, a new window is added.
Since 1 is wide, it gets split vertically and 2 is added as a's second child given the initial polarity.
This leads to Y where we insert window 3. 2 is tall and is therefore split horizontally. 3 is once again added as b's second child.
Alternate scheme
When the value of the automatic scheme is alternate, the window will be attached as if the insertion point was in manual mode and the split direction was chosen based on the split type of the insertion point's parent and the initial polarity. If the parent is split horizontally, the insertion point will be split vertically and vice versa.
Spiral scheme
When the value of the automatic scheme is spiral, the window will take the space of the insertion point.
Let's dive into the details with the following scenario:
a a a
/ \ / \ / \
1 b ---> 1 c ---> 1 d
/ \ / \ / \
2 3 4 b 5 c
^ ^ / \ ^ / \
3 2 b 4
/ \
3 2
+-----------------------+ +-----------------------+ +-----------------------+
| | | | | | | | |
| | 2 | | | 4 | | | 5 |
| | ^ | | | ^ | | | ^ |
| 1 |-----------| | 1 |-----------| | 1 |-----------|
| | | | | | | | | 3 | |
| | 3 | | | 3 | 2 | | |-----| 4 |
| | | | | | | | | 2 | |
+-----------------------+ +-----------------------+ +-----------------------+
X Y Z
In state X, the insertion point, 2 is in automatic mode.
When we add a new window, 4, the whole tree rooted at b is reattached, as the second child of a new internal node, c.
The splitting parameters of b (type: horizontal, ratio: ½) are copied to c and b is rotated by 90° clockwise.
The tiling rectangle of 4 in state Y is equal to the tiling rectangle of 2 in state X.
Then the insertion of 5, with 4 as insertion point, leads to Z.
The spiral automatic scheme generates window spirals that rotate clockwise (resp. anti-clockwise) if the insertion point is the first (resp. second) child of its parent.
Supported protocols and standards
- The RandR and Xinerama protocols.
- A subset of the EWMH and ICCCM standards.
Community
Want to get in touch with other bspwm users or you need help? Join us on our:
- Subreddit at r/bspwm.
- IRC channel at
#bspwmonirc.libera.chat(maintained by Emanuele Torre / emanuele6 on IRC). - Matrix room at https://matrix.to/#/#bspwm:matrix.org
Top Related Projects
A tiling window manager for X11
A manual tiling window manager for X11
awesome window manager
:cookie: A full-featured, hackable tiling window manager written and configured in Python (X11 + Wayland)
The core of xmonad, a small but functional ICCCM-compliant tiling window manager
i3-compatible Wayland compositor
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot