https://wiki.archlinux.org/api.php?action=feedcontributions&user=Exoro&feedformat=atomArchWiki - User contributions [en]2024-03-28T17:51:19ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Comparison_of_tiling_window_managers&diff=623595Comparison of tiling window managers2020-07-04T00:50:33Z<p>Exoro: capitalization fix of xlib under stumpwm</p>
<hr />
<div>[[Category:Tiling WMs]]<br />
[[Category:Software comparisons]]<br />
[[ja:タイル型ウィンドウマネージャの比較]]<br />
[[pt:Comparison of tiling window managers]]<br />
[[ru:Comparison of tiling window managers]]<br />
This article provides an unbiased comparison of the most popular ''tiling'' [[window manager]]s (as opposed to ''floating'' window managers).<br />
<br />
== Comparison table ==<br />
The following table lists the most popular tiling window managers alongside notable features, providing readers with a quick overview.<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
|+ Comparison of tiling window managers<br />
! scope="col" | Window Manager<br />
! scope="col" | Written in<br />
! scope="col" | Configured with<br />
! scope="col" | Management style<br />
! scope="col" | System tray support<br />
! scope="col" | On-the-fly reload<br />
! scope="col" class="unsortable" | Information bars<br />
! scope="col" | Compositing<br />
! scope="col" class="unsortable" | Default layouts<br />
! scope="col" class="unsortable" | Pixel usage<br />
! scope="col" class="unsortable" | External control<br />
! scope="col" | Library<br />
! scope="col" class="unsortable" | Multiple (n) monitor behavior<br />
! scope="col" | ICCCM/EWMH compliant<br />
! scope="col" | Maintenance<br />
|-<br />
! [[alopex]]<br />
| C || C (recompile) || Hybrid || None || No || Built-in; call script/program as first argument || External || max, h-stack, v-stack, h-tab || Variable borders, titles in-statusbar || || Xlib || six tags, two views available by default || || Active<br />
|-<br />
! [[Awesome]]<br />
| C || Lua || Dynamic || Built-in || Yes || Built-in, images and text || External || max, nh-stack (and invert), nv-stack (and invert), free || Variable borders, optional h-tab titles || dbus (if enabled) || XCB || n-tags (workspaces). Per default 9 are enabled. [https://awesomewm.org/images/6mon.medium.png Example] || Yes || Active<br />
|-<br />
! [[bspwm]]<br />
| C || Anything || Hybrid || None || Yes || Can write internal state to a FIFO || External || v-split, h-split || Variable borders || via {{ic|bspc}} || XCB || Monitors hold Desktops || Yes || Active<br />
|-<br />
! [[catwm]]<br />
| C || C (recompile) || Dynamic || None || No || None || No || v-stack, max || 1-pix borders || || Xlib || || || Abandoned<br />
|-<br />
! dswm<br />
| Lisp || Lisp || Manual || None || Yes || Yes || No || || || || || || || Abandoned<br />
|-<br />
! [[dwm]]<br />
| C || C (recompile) || Dynamic || Optional Patch || [[Dwm#Restart dwm|Optional]] || Built-in, reads from root window name || External || v-stack, max || || via [https://dwm.suckless.org/patches/dwmfifo dwmfifo] || Xlib || n regions, 9 workspaces fixed to each region || || Active<br />
|-<br />
! [[echinus]]<br />
| C || Text || Dynamic || None || Yes || {{AUR|ourico}} || External || v-stack, b-stack, max || Variable borders, optional titles || || Xlib || || Yes || Unknown<br />
|-<br />
! euclid-wm<br />
| C || Text || Hybrid || None || Yes || External ([[dzen]]) || || rows, columns || 1-pix borders || || Xlib || || || Dormant<br />
|-<br />
! [[FrankenWM]]<br />
| C || C (recompile) || Dynamic || None || No || No, outputs information to stdout, which can easily be parsed and displayed by an external monitor or panel (dzen2, conky, etc) || External || v-stack (and invert), h-stack (and invert), dual-v/h-stack, grid, fibonacci (vh-stack), rows, columns, max, free || Variable borders || || XCB || || || Active<br />
|-<br />
! [[herbstluftwm]]<br />
| C || Text || Manual || None || Yes || || || rows, columns || 1-pix borders || commands via herbstclient || Xlib and Glib || n regions, 9 workspaces visible in any region || || Active<br />
|-<br />
! [[i3]] <br />
| C || Text || Dynamic || i3bar || Yes (Layout is preserved) || text piped to i3bar ({{Ic|i3status}}/{{Ic|conky}} and others can be used) || External || tree, v-split, h-split, stacked, tabbed, max, can be nested infinitely || None, 1-pix or 2-pix, optional titlebars, can hide edge borders || commands via ipc (or i3-msg, which uses ipc) || XCB || n regions || Yes || Active<br />
|-<br />
! LeftWM<br />
| Rust || toml (user settings) / Anything (themes) || Dynamic || None || Yes || Yes, many options through theme system || External || v-stack, columns, rows || Variable based on theme || supports {{ic|_NET_ACTIVE_WINDOW}} and sending commands to a named pipe || Xlib || Workspaces and monitors are not tide. Many workspaces for monitor or many monitors for workspace || Yes || Active<br />
|-<br />
! monsterwm<br />
| C || C (recompile) || Dynamic || None || Optional, but windows are lost || No, outputs information to stdout, which can easily be parsed and displayed by an external monitor or panel ({{ic|dzen2}}, {{ic|conky}}, etc) || External || h-stack, v-stack, grid, max || || supports {{ic|_NET_ACTIVE_WINDOW}}, so external control can be supplied by {{ic|xdotool}} and similar tools || Xlib primary and XCB fork || n workspaces per monitor || || Abandoned<br />
|-<br />
! [[Musca]]<br />
| C || Text, own command set, C(recompile) || Manual || None || No, but allows running of musca commands on the fly || None || No || h-split, v-split, max || || commands, hooks || Xlib || || || Abandoned<br />
|-<br />
! [[Notion]] <br />
| C, Lua || Lua, compatible with Ion3 configs || Manual || trayion, stalonetray || Yes || configurable || ? || h-tab, max || Configurable borders and titlebars/tabs || EWMH, arbitrary Lua scripts which have access to the rich internal API || Xlib || n workspaces on each monitor. Supports on-the-fly changes in topology || || Active<br />
|-<br />
! [[qtile]] <br />
| Python || Python || Dynamic || Yes || Yes || Yes || External || tree, v-split, h-split, stacked, tabbed, max || No borders, although customizable || Hooks, Server mode || XCB || || || Active<br />
|-<br />
! [[Ratpoison]]<br />
| C || Text || Manual || None || Yes || Yes || External || max || || || || || No || Active<br />
|-<br />
! [[Snapwm]]<br />
| C || Reloadable Text || Dynamic || None || Yes || Built-in, reads from root window name || External || nVertical, Fullscreen, nHorizontal, Grid, Center Stacking || Variable borders, no titles || || Xlib || Number of desktops distributed evenly between monitors || || Active<br />
|-<br />
! [[Spectrwm]]<br />
| C || Text || Dynamic || None || Yes || Built-in, reads from user script || No || nv-stack, nh-stack, max || 1-pix borders, no titles || || XCB || n regions, 10 workspaces visible in any region || Yes || Active<br />
|-<br />
! [[Stumpwm]]<br />
| Lisp || Lisp || Manual || None || Yes || Yes || No || || || || Xlib || || No || Active<br />
|-<br />
! [[sway]] <br />
| C || Text (i3 compatible) || Dynamic || swaybar || Yes (Layout is preserved) || text piped to swaybar ({{Ic|i3status}}/{{Ic|conky}} and others can be used) || Yes || tree, v-split, h-split, stacked, tabbed, max, can be nested infinitely || None, 1-pix or 2-pix, optional titlebars, can hide edge borders || commands via ipc (or swaymsg, which uses ipc) || wlroots (wayland) || n regions || No || Active<br />
|-<br />
! [[subtle]]<br />
| C || Ruby || Manual || Built-in || Yes || Built-in (Ruby), external can be used as well || External || Variable grid || Variable borders, no titles || Hooks (Ruby), subtler (CLI), subtlext (Ruby extension) || Xlib || One workspace (view) per monitor (screen), placement on views via tags and per runtime || Yes || Active<br />
|-<br />
! [[Wingo]]<br />
| Go || Text || Dynamic || None || Yes || No || External || floating, nv-stack, nh-stack, max || title bars in floating, skinny borders in tiling || via [https://github.com/BurntSushi/wingo/blob/master/HOWTO-COMMANDS wingo-cmd] or UNIX sockets in any programming language || [https://github.com/BurntSushi/xgb X Go Binding] || n regions, workspaces visible in any region || Yes || Active<br />
|-<br />
! [[WMFS]]<br />
| C || Text || Dynamic || Built-in || Yes || Built-in, set with command, color text, images || External || nh-stack (and invert), nv-stack (and invert), mirror-v, mirror-h, grid, free, max || Variable borders, titles or no titles || commands || Xlib || Up to 36 tags(workspaces) per screen || Yes || Active<br />
|-<br />
! [[wmii]]<br />
| C || Anything || Dynamic || witray || Yes || Built-in || External || columns, max, v-tab || titles || [http://9p.cat-v.org 9P filesystem] || || one big region || Yes || Abandoned<br />
|-<br />
! [[xmonad]]<br />
| Haskell || Haskell || Dynamic || None || Yes || No || Yes, with xmonad-contrib and an external manager || nv-stack, nh-stack, max || Variable borders, no titles || via [http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ServerMode.html XMonad-Hooks-ServerMode] || Xlib || n regions, 9 workspaces visible in any region || Yes / ? || Active<br />
|-<br />
|-class="sortbottom"<br />
! Window Manager !! Written in !! Configured with !! Management style !! System tray support !! On-the-fly reload !! Information bars !! Compositing !! Default layouts !! Pixel usage || External control !! Library !! Multiple (n) monitor behavior !! ICCCM/EWMH compliant !! Maintenance<br />
|}<br />
<br />
{{Tip|External control can also be achieved by programs like {{Pkg|xdotool}} which simulate keystrokes.}}<br />
<br />
=== Management style ===<br />
Dynamic management emphasizes automatic management of window layouts for speed and simplicity. Manual management emphasizes manual adjustment of layout and sizing with potentially more precise control, at the cost of more time spent moving and sizing windows.<br />
<br />
=== Layouts ===<br />
A number of common layout types appear in several tiling WMs, although the terminology varies somewhat.<br />
* max: one window shown fullscreen (with or without a status bar, title and borders). Aka: monocle (dwm, monsterwm).<br />
* h-stack: master area in top half, other windows stack up horizontally in the bottom half. The master area may be resizable. May be inverted top-bottom (wmfs). Aka: bottom stack (dwm), bstack(monsterwm).<br />
* v-stack: master area in left half, other windows stack up vertically in the right half. The master area may be resizable. May be inverted left-right (wmfs). Aka: tile (dwm, monsterwm).<br />
* nh-stack: h-stack allowing >=1 windows in master area. Aka: nbstack (dwm)<br />
* nv-stack: v-stack allowing >=1 windows in master area. Aka: ntile (dwm)<br />
* mirror-h: nh-stack with stacks above and below the master area<br />
* mirror-v: nv-stack with stacks to the left and right of the master area<br />
* h-tab: one window shown fullscreen with all window titles shown horizontally (like browser tabs)<br />
* v-tab: one window shown fullscreen with all window titles shown vertically. Aka: stack (wmii).<br />
* h-split: a keybinding splits the current window horizontally creating space for another<br />
* v-split: a keybinding splits the current window vertically creating space for another<br />
* columns: manual layout style which treats windows as belonging to vertical columns<br />
* rows: manual layout style which treats windows as belonging to horizontal rows<br />
* grid: window positions and sizes based on a regular NxM grid. May be automatic (like wmfs, monsterwm) or manual (like Subtle).<br />
<br />
=== Key bindings ===<br />
Tiling window managers are usually designed to be used entirely with the keyboard or with keyboard & mouse. This is for speed (reaching for and moving a mouse is slow) and ease of use. Sensible key bindings are crucial to making workflow fast and efficient. Some default sets are better than others, but generally the keys can be rebound as desired by the user.<br />
<br />
== See also ==<br />
* [http://sawfish.wikia.com/wiki/Comparison_of_extensible_window_managers Comparison of extensible window managers] compares WMs "extensible" by scripting, like xmonad and Sawfish.</div>Exorohttps://wiki.archlinux.org/index.php?title=Comparison_of_tiling_window_managers&diff=623594Comparison of tiling window managers2020-07-04T00:49:36Z<p>Exoro: StumpWM uses CLX, which is just common lisp bindings for XLib. See readme for proof of CLX https://github.com/stumpwm/stumpwm</p>
<hr />
<div>[[Category:Tiling WMs]]<br />
[[Category:Software comparisons]]<br />
[[ja:タイル型ウィンドウマネージャの比較]]<br />
[[pt:Comparison of tiling window managers]]<br />
[[ru:Comparison of tiling window managers]]<br />
This article provides an unbiased comparison of the most popular ''tiling'' [[window manager]]s (as opposed to ''floating'' window managers).<br />
<br />
== Comparison table ==<br />
The following table lists the most popular tiling window managers alongside notable features, providing readers with a quick overview.<br />
<br />
{| class="wikitable sortable" style="text-align: center;"<br />
|+ Comparison of tiling window managers<br />
! scope="col" | Window Manager<br />
! scope="col" | Written in<br />
! scope="col" | Configured with<br />
! scope="col" | Management style<br />
! scope="col" | System tray support<br />
! scope="col" | On-the-fly reload<br />
! scope="col" class="unsortable" | Information bars<br />
! scope="col" | Compositing<br />
! scope="col" class="unsortable" | Default layouts<br />
! scope="col" class="unsortable" | Pixel usage<br />
! scope="col" class="unsortable" | External control<br />
! scope="col" | Library<br />
! scope="col" class="unsortable" | Multiple (n) monitor behavior<br />
! scope="col" | ICCCM/EWMH compliant<br />
! scope="col" | Maintenance<br />
|-<br />
! [[alopex]]<br />
| C || C (recompile) || Hybrid || None || No || Built-in; call script/program as first argument || External || max, h-stack, v-stack, h-tab || Variable borders, titles in-statusbar || || Xlib || six tags, two views available by default || || Active<br />
|-<br />
! [[Awesome]]<br />
| C || Lua || Dynamic || Built-in || Yes || Built-in, images and text || External || max, nh-stack (and invert), nv-stack (and invert), free || Variable borders, optional h-tab titles || dbus (if enabled) || XCB || n-tags (workspaces). Per default 9 are enabled. [https://awesomewm.org/images/6mon.medium.png Example] || Yes || Active<br />
|-<br />
! [[bspwm]]<br />
| C || Anything || Hybrid || None || Yes || Can write internal state to a FIFO || External || v-split, h-split || Variable borders || via {{ic|bspc}} || XCB || Monitors hold Desktops || Yes || Active<br />
|-<br />
! [[catwm]]<br />
| C || C (recompile) || Dynamic || None || No || None || No || v-stack, max || 1-pix borders || || Xlib || || || Abandoned<br />
|-<br />
! dswm<br />
| Lisp || Lisp || Manual || None || Yes || Yes || No || || || || || || || Abandoned<br />
|-<br />
! [[dwm]]<br />
| C || C (recompile) || Dynamic || Optional Patch || [[Dwm#Restart dwm|Optional]] || Built-in, reads from root window name || External || v-stack, max || || via [https://dwm.suckless.org/patches/dwmfifo dwmfifo] || Xlib || n regions, 9 workspaces fixed to each region || || Active<br />
|-<br />
! [[echinus]]<br />
| C || Text || Dynamic || None || Yes || {{AUR|ourico}} || External || v-stack, b-stack, max || Variable borders, optional titles || || Xlib || || Yes || Unknown<br />
|-<br />
! euclid-wm<br />
| C || Text || Hybrid || None || Yes || External ([[dzen]]) || || rows, columns || 1-pix borders || || Xlib || || || Dormant<br />
|-<br />
! [[FrankenWM]]<br />
| C || C (recompile) || Dynamic || None || No || No, outputs information to stdout, which can easily be parsed and displayed by an external monitor or panel (dzen2, conky, etc) || External || v-stack (and invert), h-stack (and invert), dual-v/h-stack, grid, fibonacci (vh-stack), rows, columns, max, free || Variable borders || || XCB || || || Active<br />
|-<br />
! [[herbstluftwm]]<br />
| C || Text || Manual || None || Yes || || || rows, columns || 1-pix borders || commands via herbstclient || Xlib and Glib || n regions, 9 workspaces visible in any region || || Active<br />
|-<br />
! [[i3]] <br />
| C || Text || Dynamic || i3bar || Yes (Layout is preserved) || text piped to i3bar ({{Ic|i3status}}/{{Ic|conky}} and others can be used) || External || tree, v-split, h-split, stacked, tabbed, max, can be nested infinitely || None, 1-pix or 2-pix, optional titlebars, can hide edge borders || commands via ipc (or i3-msg, which uses ipc) || XCB || n regions || Yes || Active<br />
|-<br />
! LeftWM<br />
| Rust || toml (user settings) / Anything (themes) || Dynamic || None || Yes || Yes, many options through theme system || External || v-stack, columns, rows || Variable based on theme || supports {{ic|_NET_ACTIVE_WINDOW}} and sending commands to a named pipe || Xlib || Workspaces and monitors are not tide. Many workspaces for monitor or many monitors for workspace || Yes || Active<br />
|-<br />
! monsterwm<br />
| C || C (recompile) || Dynamic || None || Optional, but windows are lost || No, outputs information to stdout, which can easily be parsed and displayed by an external monitor or panel ({{ic|dzen2}}, {{ic|conky}}, etc) || External || h-stack, v-stack, grid, max || || supports {{ic|_NET_ACTIVE_WINDOW}}, so external control can be supplied by {{ic|xdotool}} and similar tools || Xlib primary and XCB fork || n workspaces per monitor || || Abandoned<br />
|-<br />
! [[Musca]]<br />
| C || Text, own command set, C(recompile) || Manual || None || No, but allows running of musca commands on the fly || None || No || h-split, v-split, max || || commands, hooks || Xlib || || || Abandoned<br />
|-<br />
! [[Notion]] <br />
| C, Lua || Lua, compatible with Ion3 configs || Manual || trayion, stalonetray || Yes || configurable || ? || h-tab, max || Configurable borders and titlebars/tabs || EWMH, arbitrary Lua scripts which have access to the rich internal API || Xlib || n workspaces on each monitor. Supports on-the-fly changes in topology || || Active<br />
|-<br />
! [[qtile]] <br />
| Python || Python || Dynamic || Yes || Yes || Yes || External || tree, v-split, h-split, stacked, tabbed, max || No borders, although customizable || Hooks, Server mode || XCB || || || Active<br />
|-<br />
! [[Ratpoison]]<br />
| C || Text || Manual || None || Yes || Yes || External || max || || || || || No || Active<br />
|-<br />
! [[Snapwm]]<br />
| C || Reloadable Text || Dynamic || None || Yes || Built-in, reads from root window name || External || nVertical, Fullscreen, nHorizontal, Grid, Center Stacking || Variable borders, no titles || || Xlib || Number of desktops distributed evenly between monitors || || Active<br />
|-<br />
! [[Spectrwm]]<br />
| C || Text || Dynamic || None || Yes || Built-in, reads from user script || No || nv-stack, nh-stack, max || 1-pix borders, no titles || || XCB || n regions, 10 workspaces visible in any region || Yes || Active<br />
|-<br />
! [[Stumpwm]]<br />
| Lisp || Lisp || Manual || None || Yes || Yes || No || || || || XLib || || No || Active<br />
|-<br />
! [[sway]] <br />
| C || Text (i3 compatible) || Dynamic || swaybar || Yes (Layout is preserved) || text piped to swaybar ({{Ic|i3status}}/{{Ic|conky}} and others can be used) || Yes || tree, v-split, h-split, stacked, tabbed, max, can be nested infinitely || None, 1-pix or 2-pix, optional titlebars, can hide edge borders || commands via ipc (or swaymsg, which uses ipc) || wlroots (wayland) || n regions || No || Active<br />
|-<br />
! [[subtle]]<br />
| C || Ruby || Manual || Built-in || Yes || Built-in (Ruby), external can be used as well || External || Variable grid || Variable borders, no titles || Hooks (Ruby), subtler (CLI), subtlext (Ruby extension) || Xlib || One workspace (view) per monitor (screen), placement on views via tags and per runtime || Yes || Active<br />
|-<br />
! [[Wingo]]<br />
| Go || Text || Dynamic || None || Yes || No || External || floating, nv-stack, nh-stack, max || title bars in floating, skinny borders in tiling || via [https://github.com/BurntSushi/wingo/blob/master/HOWTO-COMMANDS wingo-cmd] or UNIX sockets in any programming language || [https://github.com/BurntSushi/xgb X Go Binding] || n regions, workspaces visible in any region || Yes || Active<br />
|-<br />
! [[WMFS]]<br />
| C || Text || Dynamic || Built-in || Yes || Built-in, set with command, color text, images || External || nh-stack (and invert), nv-stack (and invert), mirror-v, mirror-h, grid, free, max || Variable borders, titles or no titles || commands || Xlib || Up to 36 tags(workspaces) per screen || Yes || Active<br />
|-<br />
! [[wmii]]<br />
| C || Anything || Dynamic || witray || Yes || Built-in || External || columns, max, v-tab || titles || [http://9p.cat-v.org 9P filesystem] || || one big region || Yes || Abandoned<br />
|-<br />
! [[xmonad]]<br />
| Haskell || Haskell || Dynamic || None || Yes || No || Yes, with xmonad-contrib and an external manager || nv-stack, nh-stack, max || Variable borders, no titles || via [http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ServerMode.html XMonad-Hooks-ServerMode] || Xlib || n regions, 9 workspaces visible in any region || Yes / ? || Active<br />
|-<br />
|-class="sortbottom"<br />
! Window Manager !! Written in !! Configured with !! Management style !! System tray support !! On-the-fly reload !! Information bars !! Compositing !! Default layouts !! Pixel usage || External control !! Library !! Multiple (n) monitor behavior !! ICCCM/EWMH compliant !! Maintenance<br />
|}<br />
<br />
{{Tip|External control can also be achieved by programs like {{Pkg|xdotool}} which simulate keystrokes.}}<br />
<br />
=== Management style ===<br />
Dynamic management emphasizes automatic management of window layouts for speed and simplicity. Manual management emphasizes manual adjustment of layout and sizing with potentially more precise control, at the cost of more time spent moving and sizing windows.<br />
<br />
=== Layouts ===<br />
A number of common layout types appear in several tiling WMs, although the terminology varies somewhat.<br />
* max: one window shown fullscreen (with or without a status bar, title and borders). Aka: monocle (dwm, monsterwm).<br />
* h-stack: master area in top half, other windows stack up horizontally in the bottom half. The master area may be resizable. May be inverted top-bottom (wmfs). Aka: bottom stack (dwm), bstack(monsterwm).<br />
* v-stack: master area in left half, other windows stack up vertically in the right half. The master area may be resizable. May be inverted left-right (wmfs). Aka: tile (dwm, monsterwm).<br />
* nh-stack: h-stack allowing >=1 windows in master area. Aka: nbstack (dwm)<br />
* nv-stack: v-stack allowing >=1 windows in master area. Aka: ntile (dwm)<br />
* mirror-h: nh-stack with stacks above and below the master area<br />
* mirror-v: nv-stack with stacks to the left and right of the master area<br />
* h-tab: one window shown fullscreen with all window titles shown horizontally (like browser tabs)<br />
* v-tab: one window shown fullscreen with all window titles shown vertically. Aka: stack (wmii).<br />
* h-split: a keybinding splits the current window horizontally creating space for another<br />
* v-split: a keybinding splits the current window vertically creating space for another<br />
* columns: manual layout style which treats windows as belonging to vertical columns<br />
* rows: manual layout style which treats windows as belonging to horizontal rows<br />
* grid: window positions and sizes based on a regular NxM grid. May be automatic (like wmfs, monsterwm) or manual (like Subtle).<br />
<br />
=== Key bindings ===<br />
Tiling window managers are usually designed to be used entirely with the keyboard or with keyboard & mouse. This is for speed (reaching for and moving a mouse is slow) and ease of use. Sensible key bindings are crucial to making workflow fast and efficient. Some default sets are better than others, but generally the keys can be rebound as desired by the user.<br />
<br />
== See also ==<br />
* [http://sawfish.wikia.com/wiki/Comparison_of_extensible_window_managers Comparison of extensible window managers] compares WMs "extensible" by scripting, like xmonad and Sawfish.</div>Exorohttps://wiki.archlinux.org/index.php?title=Multihead&diff=546705Multihead2018-10-08T22:47:02Z<p>Exoro: Added WideGuy as a Xinerama GUI option</p>
<hr />
<div>[[Category:X server]]<br />
[[ja:マルチディスプレイ]]<br />
[[fa:Multihead]]<br />
[[zh-hans:Multihead]]<br />
{{Related articles start}}<br />
{{Related|Xorg}}<br />
{{Related|xrandr}}<br />
{{Related|NVIDIA#Multiple monitors}}<br />
{{Related|Nouveau#Dual Head}}<br />
{{Related|AMD Catalyst#Double Screen (Dual Head / Dual Screen / Xinerama)}}<br />
{{Related|ATI#Multihead setup}}<br />
{{Related|Extreme Multihead}}<br />
{{Related articles end}}<br />
<br />
'''Multi-head''', '''multi-screen''', '''multi-display''' or '''multi-monitor''' represent a setup when multiple display devices are attached to a computer. This article provides general description of multiple multi-head setup methods, and provides some examples of configuration.<br />
<br />
{{Note|The terms used in this article are very specific to avoid confusion:<br />
* '''Monitor''' refers to a physical display device, such as an LCD panel.<br />
* '''Screen''' refers to an X-Window screen (that is: a '''monitor''' attached to a '''display''').<br />
* '''Display''' refers to a collection of '''screens''' that are in use at the same time showing parts of a single desktop (you can drag windows among all '''screens''' in a single '''display''').<br />
}}<br />
<br />
== Historical background ==<br />
<br />
X Window System is the underlying graphical interface of most Unix/Linux computers providing a GUI. It was developed in 1984 at MIT. After about 35 years of development, tweaking and adding of new features and ideas, it is generally acknowledged to be a bit of a beast. It should be remembered that the common configuration at time of development was a single running X providing individual views to Xterminals in a [[Wikipedia:Time-sharing|time-sharing]] system. Nowadays the standard is X providing a single screen on a desktop or laptop.<br />
<br />
{{Note|There is still a rare configuration often called [[Xorg multiseat|Zaphod display]], which allows multiple users of a single computer to each have an independent set of display, mouse, and keyboard, as though they were using separate computers, but at a lower per-seat cost.}}<br />
<br />
All of this means that there are many ways of achieving the same thing and many slightly different things that can meet the same purpose. In modern X versions sometimes you can get away with limited or no configuration. In the last few years the boast is that X is self configuring. Certainly the best practice rule of thumb is less configuration is better - that is ''only configure what is wrong''.<br />
<br />
== Separate screens ==<br />
<br />
This is the original way of configuring multiple monitors with X, and it has been around for decades. Each physical monitor is assigned as an X screen, and while you can move the mouse between them, they are more or less independent.<br />
<br />
Normally the X display has a single identifier such as {{ic|:0}} set in the {{ic|DISPLAY}} environment variable, but in this configuration each screen has a different {{ic|$DISPLAY}} value. The first screen is {{ic|:0.0}}, the second is {{ic|:0.1}} and so on.<br />
<br />
With this configuration it is not possible to move windows between screens, apart from a few special programs like GIMP and Emacs which have multi-screen support. For most programs you must change the {{ic|DISPLAY}} environment variable when launching to have the program appear on another screen:<br />
<br />
# Launch a terminal on the second screen<br />
$ DISPLAY=:0.1 urxvt &<br />
<br />
Alternatively if you have a terminal on each screen launching programs will inherit the {{ic|DISPLAY}} value and appear on the same screen they were launched on. But moving an application between screens involves closing it and reopening it again on the other screen.<br />
<br />
Working this way does have certain advantages, such as windows popping up on one screen won't steal the focus away from you if you are working on another screen - each screen is quite independent.<br />
<br />
== RandR ==<br />
<br />
[[Wikipedia:RandR|RandR]] ('''R'''otate '''and''' '''R'''esize) is an [[Wikipedia:X Window System|X Window System]] extension, which allows clients to dynamically change (e.g. resize, rotate, reflect) screens. In most cases, it can fully replace the old Xinerama setup. See [http://i3wm.org/docs/multi-monitor.html#_the_explanation an explanation] why RandR is better than Xinerama.<br />
<br />
RandR can be configured for the current session via the [[xrandr]] tool or persistently via an [[xorg.conf]] file.<br />
<br />
{{Note|There are multiple ways to configure the same thing, you might have to experiment a little before you find the best configuration.}}<br />
<br />
=== Configuration using xrandr ===<br />
<br />
{{Note|This section assumes that you have read the [[xrandr]] page for basic info about ''xrandr''.}}<br />
<br />
You may arrange your screens either relatively to each other (using the {{ic|--right-of}}, {{ic|--left-of}}, {{ic|--above}}, {{ic|--below}} options), or by absolute coordinates (using the {{ic|--pos}} option; note that in this case you usually need to know resolutions of your monitors). See {{man|1|xrandr}} for details. Some frequently used settings are described below.<br />
<br />
==== VGA1 left of HDMI1 at their preferred resolutions ====<br />
<br />
$ xrandr --output VGA1 --auto --output HDMI1 --auto --right-of VGA1<br />
<br />
{{ic|--right-of}} places the previous screen ({{ic|HDMI1}}) to the right of the specified screen ({{ic|VGA1}}).<br />
<br />
==== VGA1 right of HDMI1 at fixed resolutions ====<br />
<br />
$ xrandr --output VGA1 --mode 1024x768 --pos 1920x0 --output HDMI1 --mode 1920x1080 --pos 0x0<br />
<br />
or<br />
<br />
$ xrandr --output VGA1 --mode 1024x768 --output HDMI1 --mode 1920x1080 --left-of VGA1<br />
<br />
{{ic|--left-of}} places the previous screen ({{ic|HDMI1}}) to the left of the specified screen ({{ic|VGA1}}).<br />
<br />
=== Configuration using xorg.conf ===<br />
<br />
This is similar to using ''xrandr'', separate {{ic|Monitor}} section is needed for each screen. As an {{ic|Identifier}}, the same value as reported by {{ic|xrandr -q}} is used (i.e. {{ic|Identifier "VGA1"}} is used instead of {{ic|--output VGA1}}).<br />
<br />
==== Example: dualhead configuration using relative coordinates ====<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "Monitor"<br />
Identifier "VGA1"<br />
Option "Primary" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "HDMI1"<br />
Option "LeftOf" "VGA1"<br />
EndSection<br />
}}<br />
<br />
==== Example: dualhead configuration using relative coordinates with custom resolutions ====<br />
The ID for each monitor can be found by running the {{ic|$ xrandr -q}} command and should be defined as {{ic|Monitor-<ID>}} inside the {{ic|Device}} section.<br />
<br />
See [[Xrandr#Adding undetected resolutions]].<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "Monitor"<br />
Identifier "DVI"<br />
Modeline "1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync<br />
Option "PreferredMode" "1680x1050_60.00"<br />
Option "LeftOf" "DP"<br />
Option "DPMS" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "DP"<br />
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync<br />
Option "PreferredMode" "1920x1080_60.00"<br />
Option "RightOf" "DVI"<br />
Option "DPMS" "true"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "Radeon" # e.g. Radeon, Intel, nvidia<br />
Monitor "DP"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
Virtual 3600 2130 # 1920 + 1680 (3600), 1080 + 1050 (2130)<br />
EndSubSection<br />
EndSection<br />
}}<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-radeon.conf|<br />
Section "Device"<br />
Identifier "Radeon"<br />
Driver "radeon"<br />
Option "Monitor-DVI-0" "DVI" # use DVI-0 as DVI<br />
Option "Monitor-DisplayPort-0" "DP"<br />
EndSection<br />
}}<br />
<br />
==== Example: dualhead configuration using absolute coordinates ====<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "Monitor"<br />
Identifier "VGA1"<br />
Option "PreferredMode" "1024x768"<br />
Option "Position" "1920 312"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "HDMI1"<br />
Option "PreferredMode" "1920x1080"<br />
Option "Position" "0 0"<br />
EndSection<br />
}}<br />
<br />
There are no negative coordinates, the setup's leftmost and highest possibly targeted point is at 0,0<br />
<br />
{{Text art|<nowiki><br />
(0,0)-----------------+ <br />
| |(1920,312)---+<br />
| 1920 x 1080 || |<br />
| HDMI1 || 1024 x 768 |<br />
| || VGA1 |<br />
+---------------------++------------+<br />
</nowiki>}}<br />
<br />
== TwinView ==<br />
<br />
TwinView is [[NVIDIA]]'s extension which makes two monitors attached to a video card appear as a single screen. TwinView provides Xinerama extensions so that applications are aware there are two monitors connected, and thus it is incompatible with Xinerama. However if you only have two monitors and they are both connected to the same NVIDIA card, there is little difference between TwinView and Xinerama (although in this situation TwinView may offer slightly better performance.)<br />
<br />
If you wish to attach more than two monitors or monitors attached to other video cards, you will need to use Xinerama instead of TwinView. Likewise as of April 2012, both monitors must be in the same orientation - you cannot have one in landscape and the other in portrait mode.<br />
<br />
In the past, TwinView was the only way to get OpenGL acceleration with NVIDIA cards while being able to drag windows between screens. However modern versions of the NVIDIA closed-source driver are able to provide OpenGL acceleration even when using Xinerama.<br />
<br />
See [[NVIDIA#TwinView]] for an example configuration.<br />
<br />
== Xinerama ==<br />
<br />
[[Wikipedia:Xinerama|Xinerama]] is the old way of doing genuine multihead X. Xinerama combines all monitors into a single screen ({{ic|:0}}) making it possible to drag windows between screens.<br />
<br />
Xinerama is configured via custom [[Xorg#Configuration|X configuration files]]. There is also a GUI tool named [https://openapplibrary.org/project/wideguy WideGuy] to make toggling Xinerama easier. Note that to use WideGuy you still need an Xorg configuration with a ServerLayout section.<br />
<br />
Here are some [[Xorg#Configuration|X configuration]] examples:<br />
<br />
This is a ServerLayout section which controls where each monitor sits relative to the others.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/90-serverlayout.conf|<br />
Section "ServerLayout"<br />
Identifier "Main"<br />
Screen 0 "Primary"<br />
Screen 1 "DellPortraitLeft" RightOf "Primary"<br />
Screen 2 "Wacom" RightOf "DellPortraitLeft"<br />
Screen 3 "U2412" LeftOf "Primary"<br />
Option "Xinerama" "1" # enable XINERAMA extension. Default is disabled.<br />
EndSection<br />
}}<br />
<br />
Each Screen in the above section is defined in a separate file, such as this one:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/30-screen-dell2001.conf|<br />
# Define the monitor's physical specs<br />
Section "Monitor"<br />
Identifier "Dell 2001FP"<br />
VertRefresh 60<br />
Option "dpms" "on"<br />
<br />
# Modelines are probably unnecessary these days, but it does give you fine grained control<br />
<br />
# 1600x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 160.96 MHz<br />
Modeline "1600x1200" 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -HSync +Vsync<br />
EndSection<br />
<br />
# Define a screen that uses the above monitor. Note the Monitor value matches the above<br />
# Identifier value, and the Device value matches one of the video cards defined below<br />
# (the card and connector this monitor is actually plugged in to.)<br />
Section "Screen"<br />
Identifier "DellPortraitLeft"<br />
Device "GeForce 8600GTb"<br />
Monitor "Dell 2001FP"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1600x1200"<br />
ViewPort 0 0<br />
Virtual 1600 1200<br />
EndSubsection<br />
<br />
# This screen is in portrait mode<br />
Option "Rotate" "left"<br />
EndSection<br />
}}<br />
<br />
You will need to create a {{ic|Device}} section for each '''monitor''', i.e. a dual head video card will have two Device sections. The following example shows how to configure two video cards each providing two outputs, for a total of four monitors.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|<br />
# First head of first video card in the system<br />
Section "Device"<br />
Identifier "GeForce 8600GT"<br />
Driver "nvidia"<br />
<br />
# If you have multiple video cards, the BusID controls which one this definition refers<br />
# to. You can omit it if you only have one card.<br />
BusID "PCI:1:0:0"<br />
<br />
# Need to flag this as only referring to one output on the card<br />
Screen 0<br />
<br />
# For nVidia devices, this controls which connector the monitor is connected to.<br />
Option "UseDisplayDevice" "DFP-0"<br />
<br />
# We want control!<br />
Option "DynamicTwinView" "FALSE"<br />
<br />
# Various performance and configuration options<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
EndSection<br />
<br />
# Second head of same video card (note different Identifier but same BusID.) We can omit<br />
# the UseDisplayDevice option this time as it will pick whichever one is remaining.<br />
Section "Device"<br />
Identifier "GeForce 8600GTb"<br />
Driver "nvidia"<br />
BusID "PCI:1:0:0"<br />
# This is the second output on this card<br />
Screen 1<br />
<br />
# Same config options for all cards<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
Option "DynamicTwinView" "FALSE"<br />
EndSection<br />
<br />
# First head of second video card, note different BusID.<br />
Section "Device"<br />
Identifier "G210"<br />
Driver "nvidia"<br />
BusID "PCI:2:0:0"<br />
Screen 0<br />
<br />
# Same config options for all cards<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
Option "DynamicTwinView" "FALSE"<br />
EndSection<br />
<br />
# Second head of second video card. Output connector is set here, which means the previous<br />
# Device will use the other connector, whatever it may be.<br />
Section "Device"<br />
Identifier "G210b"<br />
Driver "nvidia"<br />
BusID "PCI:2:0:0"<br />
Screen 1<br />
Option "UseDisplayDevice" "DFP-1"<br />
<br />
# Same config options for all cards<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
Option "DynamicTwinView" "FALSE"<br />
EndSection<br />
}}<br />
<br />
== Application support ==<br />
<br />
{{Out of date|This section contains outdated information, mostly specific to Xinerama.}}<br />
<br />
This section lists tips for individual applications.<br />
<br />
* mplayer: use {{ic|-xineramascreen 1}} to make the video play on screen #1 (the second screen.) Add {{ic|1=xineramascreen=1}} to {{ic|~/.mplayer/config}} to make it permanent.<br />
* Xonotic: if you are playing across multiple screens and you are unable to turn left/right properly, set {{ic|vid_stick_mouse}} to 1 in {{ic|~/.xonotic/data/config.cfg}}<br />
<br />
=== Window managers ===<br />
<br />
This section lists window managers and how they cope with multiple monitors.<br />
<br />
* [[Awesome]] - Works<br />
* [[FVWM]] - Works. Has support for Xinerama and multi-screen display, such as Single Logical Screen. <br />
* [[i3]] - Works<br />
* [[KDE]] - Works<br />
* [[MATE]] - Works<br />
* [[Qtile]] - Works<br />
* [[Spectrwm]] - Works (screens are different workspaces, both accessible and switching is possible by both keyboard and mouse) - as of March 2015<br />
* [[Xmonad]] - Works (screens are different workspaces, both accessible and switching is possible by both keyboard and mouse) - as of April 2014<br />
<br />
=== Display managers ===<br />
<br />
[[GDM]]: see [[GDM#Setup default monitor settings]].<br />
<br />
Users may prefer to use {{ic|startx}} and {{ic|~/.xinitrc}} instead of a display manager due to the lack of working support with multiple displays.<br />
<br />
=== Full screen games ===<br />
<br />
Many games require their window to appear at (0,0) when running in full-screen. If the screen you have at (0,0) - the left-most one - is not one you wish to game on, it is almost impossible to move a full-screen game onto a different screen.<br />
<br />
A workaround for this is to create a separate X11 configuration (a new '''layout''') just for playing games, which may have less (or only one) screen configured. You can then launch games using this separate layout, while normal desktop work uses the original multihead configuration.<br />
<br />
To create a new layout, copy {{ic|/etc/X11/xorg.d/90-serverlayout.conf}} and call it {{ic|91-serverlayout-gaming.conf}}. It is important to use a number larger than 90, as the one with the lowest number will become the default used when you first load X.<br />
<br />
Adjust this new configuration file to your preferred gaming configuration. Here is an example (based on the example Xinerama configuration above) with only one screen defined, noting that the screen specifics (such as resolution) are defined in other files and are unchanged from and shared with the normal configuration:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/91-serverlayout-gaming.conf|<br />
# New screen layout only using a single screen called "Primary"<br />
Section "ServerLayout"<br />
Identifier "Gaming"<br />
Screen 0 "Primary" Absolute 0 0<br />
EndSection<br />
}}<br />
<br />
{{Tip|While it's easiest to just reuse the existing screen definitions, you can of course define new ones if you wish to have a different set of screen resolutions available.}}<br />
<br />
To use this new layout, launch the game via the {{ic|startx}} script:<br />
<br />
# Launch Xonotic on a new X11 display using the "Gaming" layout<br />
startx /usr/bin/xonotic-glx -fullscreen -- :1 -layout Gaming<br />
<br />
Note that:<br />
* You must specify the full path to the command to run, here {{ic|/usr/bin/xonotic-glx}}.<br />
* The {{ic|:1}} must refer to an empty unused display. The first display you are likely using for your desktop is {{ic|:0}}, so {{ic|:1}} will be fine for most people. But should you want to launch a second game at the same time, you would have to change this to {{ic|:2}}.<br />
* Just as you can switch between text consoles with Alt+Ctrl+F1 and back to X with Alt+Ctrl+F7, the new display will sit on Alt+Ctrl+F8. So you can switch back to your desktop with Alt+Ctrl+F7 and back to the game with Alt+Ctrl+F8. This is because you are running an independent X desktop, so if you switch out of the game with Alt+Tab or equivalent there will be an empty desktop with no window manager running.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=652861 'How I got Dual Monitors with Nouveau Driver' forums thread]<br />
* [http://linuxgazette.net/124/smith.html Six-headed, Six-user Linux System]</div>Exorohttps://wiki.archlinux.org/index.php?title=Window_manager&diff=526405Window manager2018-06-16T13:50:43Z<p>Exoro: Changed the language of Flwm from first-person to third.</p>
<hr />
<div>[[Category:Graphical user interfaces]]<br />
[[ar:Window manager]]<br />
[[es:Window manager]]<br />
[[fa:Window manager]]<br />
[[it:Window manager]]<br />
[[ja:ウィンドウマネージャ]]<br />
[[ko:Window manager]]<br />
[[pt:Window manager]]<br />
[[ru:Window manager]]<br />
[[zh-hans:Window manager]]<br />
{{Related articles start}}<br />
{{Related|Xdg-menu}}<br />
{{Related|Xorg}}<br />
{{Related|xinit}}<br />
{{Related|Start X at Login}}<br />
{{Related articles end}}<br />
<br />
A [[Wikipedia:Window manager|window manager]] (WM) is system software that controls the placement and appearance of windows within a windowing system in a graphical user interface (GUI). It can be part of a [[desktop environment]] (DE) or be used standalone.<br />
<br />
== Overview ==<br />
<br />
Window managers are X clients that control the appearance and behaviour of the frames ("windows") where the various graphical applications are drawn. They determine the border, titlebar, size, and ability to resize windows, and often provide other functionality such as reserved areas for sticking [http://windowmaker.org/dockapps/ dockapps] like [[Window Maker]], or the ability to tab windows like [[Fluxbox]]. Some window managers are even bundled with simple utilities like menus to start programs or to configure the WM itself.<br />
<br />
The [http://standards.freedesktop.org/wm-spec/wm-spec-latest.html Extended Window Manager Hints] specification is used to allow window managers interact in standard ways with the server and the other clients.<br />
<br />
Some window managers are developed as part of a more comprehensive [[desktop environment]], usually allowing the other provided applications to better interact with each other, giving a more consistent experience to the user, complete with features like desktop icons, fonts, toolbars, wallpapers, or desktop widgets.<br />
<br />
Other window managers are instead designed to be used ''standalone'', giving the user complete freedom over the choice of the other applications to be used. This allows the user to create a more lightweight and customized environment, tailored to his/her own specific needs. "Extras" like desktop icons, toolbars, wallpapers, or desktop widgets, if needed, will have to be added with additional dedicated applications.<br />
<br />
Some standalone WMs can be also used to replace the default WM of a DE, just like some DE-oriented WMs can be used standalone too.<br />
<br />
Prior to installing a window manager, a functional X server installation is required. See [[Xorg]] for detailed information.<br />
<br />
=== Types ===<br />
<br />
* [[#Stacking window managers|Stacking]] (aka floating) window managers provide the traditional desktop metaphor used in commercial operating systems like Windows and OS X. Windows act like pieces of paper on a desk, and can be stacked on top of each other. For available Arch Wiki pages see [[:Category:Stacking WMs]].<br />
* [[#Tiling window managers|Tiling]] window managers "tile" the windows so that none are overlapping. They usually make very extensive use of key-bindings and have less (or no) reliance on the mouse. Tiling window managers may be manual, offer predefined layouts, or both. For available Arch Wiki pages see [[:Category:Tiling WMs]].<br />
* [[#Dynamic window managers|Dynamic]] window managers can dynamically switch between tiling or floating window layout. For available Arch Wiki pages see [[:Category:Dynamic WMs]].<br />
<br />
See [[Comparison of tiling window managers]] and [[Wikipedia:Comparison of X window managers]] for comparison of window managers.<br />
<br />
== List of window managers==<br />
<br />
=== Stacking window managers ===<br />
<br />
* {{App|[[2bwm]]|Fast floating WM, with the particularity of having 2 borders, written over the XCB library and derived from mcwm written by Michael Cardell. In 2bwm everything is accessible from the keyboard but a pointing device can be used for move, resize and raise/lower. The name has recently changed from mcwm-beast to 2bwm.|https://github.com/venam/2bwm|{{AUR|2bwm}}}}<br />
<br />
* {{App|aewm|Modern, minimal window manager for X11. It is controlled entirely with the mouse, but contains no visible UI apart from window frames. The command set is sort of like vi: designed back in the dawn of time (1997) to squeeze speed out of low-memory machines, completely unintuitive and new-user-hostile, but quick and elegant in its own way.|http://www.red-bean.com/decklin/aewm/|{{AUR|aewm}}}}<br />
<br />
* {{App|[[Wikipedia:AfterStep|AfterStep]]|Window manager for the Unix X Window System. Originally based on the look and feel of the NeXTStep interface, it provides end users with a consistent, clean, and elegant desktop. The goal of AfterStep development is to provide for flexibility of desktop configuration, improving aesthetics, and efficient use of system resources.|http://www.afterstep.org/|{{AUR|afterstep-git}}}}<br />
<br />
* {{App|[[Blackbox]]|Fast, lightweight window manager for the X Window System, without all those annoying library dependencies. Blackbox is built with C++ and contains completely original code (even though the graphics implementation is similar to that of WindowMaker).|http://blackboxwm.sourceforge.net/|{{Pkg|blackbox}}}}<br />
<br />
* {{App|[[Compiz]]|OpenGL compositing manager that uses GLX_EXT_texture_from_pixmap for binding redirected top-level windows to texture objects. It has a flexible plug-in system and it is designed to run well on most graphics hardware.|https://launchpad.net/compiz|{{AUR|compiz}}, {{AUR|compiz-core}}}}<br />
<br />
* {{App|[[cwm]]|Originally deriving from evilwm, but later re-written from scratch. cwm aims to be simple, and offers helpful features such as searching for windows.|https://github.com/chneukirchen/cwm|{{AUR|cwm}}}}<br />
<br />
* {{App|eggwm|A lightweight QT4/QT5 window manager|{{AUR|eggwm-qt5}}|{{AUR|eggwm}}}}<br />
<br />
* {{App|[[Enlightenment]]|Enlightenment is not just a window manager for Linux/X11 and others, but also a whole suite of libraries to help you create beautiful user interfaces with much less work than doing it the old fashioned way and fighting with traditional toolkits, not to mention a traditional window manager.|http://www.enlightenment.org/|{{Pkg|enlightenment}}}}<br />
<br />
* {{App|[[evilwm]]|Minimalist window manager for the X Window System. 'Minimalist' here does not mean it is too bare to be usable - it just means it omits a lot of the stuff that make other window managers ''un''usable.|http://www.6809.org.uk/evilwm/|{{AUR|evilwm}}}}<br />
<br />
* {{App|[[Fluxbox]]|Window manager for X that was based on the Blackbox 0.61.1 code. It is very light on resources and easy to handle but yet full of features to make an easy and extremely fast desktop experience. It is built using C++ and licensed under the MIT License.|https://github.com/fluxbox/fluxbox|{{Pkg|fluxbox}}}}<br />
<br />
* {{App|[[Wikipedia:FLWM|Flwm]]|The creator of Flwm aimed to combine the best ideas from several window managers. The primary influence and code base is from wm2 by Chris Cannam.|http://flwm.sourceforge.net/|{{AUR|flwm}}}}<br />
<br />
* {{App|[[FVWM]]|Extremely powerful ICCCM-compliant multiple virtual desktop window manager for the X Window system. Development is active, and support is excellent.|http://www.fvwm.org/|{{Pkg|fvwm}}}}<br />
<br />
* {{app|[http://elementaryos.org/journal/meet-gala-window-manager Gala]|A beautiful Window Manager from elementaryos, part of [[Pantheon]]. Also as a compositing manager, based on libmutter.|https://launchpad.net/gala|{{aur|gala}}, {{aur|gala-git}} }}<br />
<br />
* {{App|Goomwwm|X11 window manager implemented in C as a cleanroom software project. It manages windows in a minimal floating layout, while providing flexible keyboard-driven controls for window switching, sizing, moving, tagging, and tiling. It is also fast, lightweight, modeless, Xinerama-aware, and EWMH compatible wherever possible.|https://github.com/seanpringle/goomwwm|{{AUR|goomwwm}}}}<br />
<br />
* {{App|[[IceWM]]|Window manager for the X Window System. The goal of IceWM is speed, simplicity, and not getting in the user's way.|http://www.icewm.org/|{{Pkg|icewm}}}}<br />
<br />
* {{App|jbwm|jbwm is a window manager based on evilwm, with a minimal configuration size of approximately 16kb, focused on small binary size and usability, incorporating optional title-bars and XFT title-bar font rendering as compile-time options. jbwm also features easier to use keybindings than evilwm.|https://github.com/jefbed/jbwm|{{AUR|jbwm}}}}<br />
<br />
* {{App|[[JWM]]|Window manager for the X11 Window System. JWM is written in C and uses only Xlib at a minimum.|https://joewing.net/projects/jwm/index.shtml|{{Pkg|jwm}}}}<br />
<br />
* {{App|Karmen|Window manager for X, written by Johan Veenhuizen. It is designed to "just work." There is no configuration file and no library dependencies other than Xlib. The input focus model is click-to-focus. Karmen aims at ICCCM and EWMH compliance.|http://karmen.sourceforge.net/|{{AUR|karmen}}}}<br />
<br />
* {{App|[[Wikipedia:KWin|KWin]]|The standard KDE window manager since KDE 4.0, ships with the first version of built-in support for compositing, making it also a compositing manager. This allows KWin to provide advanced graphical effects, similar to Compiz, while also providing all the features from previous KDE releases (such as very good integration with the rest of KDE, advanced configurability, focus stealing prevention, a well-tested window manager, robust handling of misbehaving applications/toolkits, etc.). Also serves as a compositor for [[Wayland]].|https://techbase.kde.org/Projects/KWin|{{Pkg|kwin}}}}<br />
<br />
* {{App|lwm|Window manager for X that tries to keep out of your face. There are no icons, no button bars, no icon docks, no root menus, no nothing: if you want all that, then other programs can provide it. There is no configurability either: if you want that, you want a different window manager; one that helps your operating system in its evil conquest of your disc space and its annexation of your physical memory.|http://www.jfc.org.uk/software/lwm.html|{{Pkg|lwm}}}}<br />
<br />
* {{App|Marco|The MATE window manager, fork of Metacity.|https://github.com/mate-desktop/marco|{{Pkg|marco}}}}<br />
<br />
* {{App|[[Wikipedia:Metacity|Metacity]]|This window manager strives to be quiet, small, stable, get on with its job, and stay out of your attention. It is used by the legacy GNOME 2 and GNOME flashback sessions, and superseded by Mutter.|https://blogs.gnome.org/metacity/|{{Pkg|metacity}}}}<br />
<br />
* {{App|[[Wikipedia:Mutter_(software)#Muffin|Muffin]]|Window and compositing manager for Cinnamon, fork of Mutter, based on Clutter, uses OpenGL. It cannot be used outside of Cinnamon.|https://github.com/linuxmint/muffin/|{{Pkg|muffin}}}}<br />
<br />
* {{App|[[Wikipedia:Mutter (window manager)|Mutter]]|Window and compositing manager for GNOME, based on Clutter, uses OpenGL. Also serves a Wayland compositor.|https://git.gnome.org/browse/mutter/|{{Pkg|mutter}}}}<br />
<br />
* {{App|[[Wikipedia:Motif_Window_Manager|MWM]]|The Motif Window Manager (MWM) is an X window manager based on the Motif toolkit.|http://sourceforge.net/projects/motif/|{{Pkg|openmotif}}}}<br />
<br />
* {{App|[[Openbox]]|Highly configurable, next generation window manager with extensive standards support. The *box visual style is well known for its minimalistic appearance. Openbox uses the *box visual style, while providing a greater number of options for theme developers than previous *box implementations. The theme documentation describes the full range of options found in Openbox themes.|http://openbox.org/|{{Pkg|openbox}}}}<br />
<br />
* {{App|[[pawm]]|Window manager for the X Window system. So it is not a 'desktop' and does not offer you a huge pile of useless options, just the facilities needed to run your X applications and at the same time having a friendly and easy to use interface.|http://www.pleyades.net/pawm/|{{AUR|pawm}}}}<br />
<br />
* {{App|[[PekWM]]|Window manager that once upon a time was based on the aewm++ window manager, but it has evolved enough that it no longer resembles aewm++ at all. It has a much expanded feature-set, including window grouping (similar to Ion, PWM, or Fluxbox), auto-properties, Xinerama, keygrabber that supports keychains, and much more.|https://www.pekwm.org/|{{Pkg|pekwm}}}}<br />
<br />
* {{App|[[Sawfish]]|Extensible window manager using a Lisp-based scripting language. Its policy is very minimal compared to most window managers. Its aim is simply to manage windows in the most flexible and attractive manner possible. All high-level WM functions are implemented in Lisp for future extensibility or redefinition.|http://sawfish.wikia.com/wiki/Main_Page|{{AUR|sawfish}}}}<br />
<br />
* {{App|TinyWM|Tiny window manager created as an exercise in minimalism. It may be helpful in learning some of the very basics of creating a window manager. It is comprised of approximately 50 lines of C. There is also a Python version using python-xlib.|http://incise.org/tinywm.html|{{AUR|tinywm}} {{AUR|tinywm-git}}}}<br />
<br />
* {{App|[[twm]]|Window manager for the X Window System. It provides titlebars, shaped windows, several forms of icon management, user-defined macro functions, click-to-type and pointer-driven keyboard focus, and user-specified key and pointer button bindings.|https://cgit.freedesktop.org/xorg/app/twm/|{{Pkg|xorg-twm}}}}<br />
<br />
* {{App|[[Wikipedia:UDE|UWM]]|The ultimate window manager for UDE.|http://udeproject.sourceforge.net/|{{AUR|ude}}}}<br />
<br />
* {{App|WindowLab|Small and simple window manager of novel design. It has a click-to-focus but not raise-on-focus policy, a window resizing mechanism that allows one or many edges of a window to be changed in one action, and an innovative menubar that shares the same part of the screen as the taskbar. Window titlebars are prevented from going off the edge of the screen by constraining the mouse pointer, and when appropriate the pointer is also constrained to the taskbar/menubar in order to make target menu items easier to hit.|https://github.com/nickgravgaard/windowlab|{{Pkg|windowlab}}{{Broken package link|package not found}}}}<br />
<br />
* {{App|[[Window Maker]]|X11 window manager originally designed to provide integration support for the GNUstep Desktop Environment. In every way possible, it reproduces the elegant look and feel of the NEXTSTEP user interface. It is fast, feature rich, easy to configure, and easy to use. It is also free software, with contributions being made by programmers from around the world.|https://windowmaker.org/|{{AUR|windowmaker}}}}<br />
<br />
* {{App|WM2|Window manager for X. It provides an unusual style of window decoration and as little functionality as its author feels comfortable with in a window manager. wm2 is not configurable, except by editing the source and recompiling the code, and is really intended for people who do not particularly want their window manager to be too friendly. |http://www.all-day-breakfast.com/wm2/|{{AUR|wm2}}}}<br />
<br />
* {{App|[[Xfwm]]|The [[Xfce]] window manager manages the placement of application windows on the screen, provides beautiful window decorations, manages workspaces or virtual desktops and natively supports multiscreen mode. It provides its own compositing manager (from the X.Org Composite extension) for true transparency and shadows. The Xfce window manager also includes a keyboard shortcuts editor for user specific commands and basic windows manipulations and provides a preferences dialog for advanced tweaks.|https://docs.xfce.org/xfce/xfwm4/start|{{pkg|xfwm4}}}}<br />
<br />
=== Tiling window managers ===<br />
<br />
* {{App|[[Bspwm]]|bspwm is a tiling window manager that represents windows as the leaves of a full binary tree. It has support for EWMH and multiple monitors, and is configured and controlled through messages.|https://github.com/baskerville/bspwm|{{Pkg|bspwm}}}}<br />
<br />
* {{App|[[EXWM]]|EXWM (Emacs X Window Manager) is a full-featured tiling X window manager for Emacs built on top of XELB. It features fully keyboard-driven operations, hybrid layout modes (tiling & stacking), dynamic workspace support, ICCCM/EWMH compliance, RandR (multi-monitor) support, and a built-in system tray.|https://github.com/ch11ng/exwm|{{AUR|emacs-exwm-git}}}}<br />
<br />
* {{App|[[Herbstluftwm]]|Manual tiling window manager for X11 using Xlib and Glib. The layout is based on splitting frames into subframes which can be split again or can be filled with windows (similar to i3/ musca). Tags (or workspaces or virtual desktops or …) can be added/removed at runtime. Each tag contains its own layout. Exactly one tag is viewed on each monitor. The tags are monitor independent (similar to xmonad). It is configured at runtime via ipc calls from herbstclient. So the configuration file is just a script which is run on startup. (similar to wmii/musca).|https://herbstluftwm.org|{{pkg|herbstluftwm}}}}<br />
<br />
* {{App|howm|A lightweight, tiling X11 window manager that mimics vi by offering operators, motions and modes. Configuration is done through the included {{ic|config.h}} file.|https://github.com/HarveyHunt/howm|{{AUR|howm-x11}}}}<br />
<br />
* {{App|[[i3]]|Tiling window manager, completely written from scratch. i3 was created because wmii, our favorite window manager at the time, did not provide some features we wanted (multi-monitor done right, for example), had some bugs, did not progress for quite some time, and was not easy to hack at all (source code comments/documentation completely lacking). Notable differences are in the areas of multi-monitor support and the tree metaphor. For speed the Plan 9 interface of wmii is not implemented. |https://i3wm.org/|{{Pkg|i3-wm}}}}<br />
<br />
* {{App|[[Ion3]]|Tiling tabbed X11 window manager designed with keyboard users in mind. It was one of the first of the “new wave" of tiling windowing environments (the other being LarsWM, with quite a different approach) and has since spawned an entire category of tiling window managers for X11 – none of which really manage to reproduce the feel and functionality of Ion. It uses Lua as an embedded interpreter which handles all of the configuration. |http://tuomov.iki.fi/software|{{AUR|ion3}}}}<br />
<br />
* {{App|[[Notion]]|Tiling, tabbed window manager for the X window system that utilizes 'tiles' and 'tabbed' windows.<br />
** Tiling: you divide the screen into non-overlapping 'tiles'. Every window occupies one tile, and is maximized to it<br />
** Tabbing: a tile may contain multiple windows - they will be 'tabbed'.<br />
** Static: most tiled window managers are 'dynamic', meaning they automatically resize and move around tiles as windows appear and disappear. Notion, by contrast, does not automatically change the tiling.<br />
: Notion is a fork of Ion3.|http://notion.sf.net/|{{Pkg|notion}}}}<br />
<br />
* {{App|[[Ratpoison]]|Simple Window Manager with no fat library dependencies, no fancy graphics, no window decorations, and no rodent dependence. It is largely modeled after GNU Screen which has done wonders in the virtual terminal market. Ratpoison is configured with a simple text file. The information bar in Ratpoison is somewhat different, as it shows only when needed. It serves as both an application launcher as well as a notification bar. Ratpoison does not include a system tray.|http://www.nongnu.org/ratpoison/|{{Pkg|ratpoison}}}}<br />
<br />
* {{App|[[Stumpwm]]|Tiling, keyboard driven X11 Window Manager written entirely in Common Lisp. Stumpwm attempts to be customizable yet visually minimal. It does have various hooks to attach your personal customizations, and variables to tweak, and can be reconfigured and reloaded while running. There are no window decorations, no icons, no buttons, and no system tray. Its information bar can be set to show constantly or only when needed.|https://stumpwm.github.io/|{{AUR|stumpwm-git}}}}<br />
<br />
* {{App|[[subtle]]|Manual tiling window manager with a rather uncommon approach of tiling: Per default there is no typical layout enforcement, windows are placed on a position (gravity) in a custom grid. The user can change the gravity of each window either directly per grabs or with rules defined by tags in the config. It has workspace tags and automatic client tagging, mouse and keyboard control as well as an extendable statusbar. |http://subforge.org/projects/subtle|{{AUR|subtle-git}}}}<br />
<br />
* {{App|[[sway]]| Sway is a drop-in replacement for the i3 window manager, but for Wayland instead of X11. It works with your existing i3 configuration and supports most of i3's features, and a few extras.|http://swaywm.org/|{{Pkg|sway}}}}<br />
<br />
* {{App|way-cooler| Way Cooler is a tiling Wayland window manager, written in Rust, configurable using Lua, and extendable with D-Bus.|http://way-cooler.org/|{{AUR|way-cooler}}}}<br />
<br />
* {{App|[[WMFS]]|Window Manager From Scratch is a lightweight and highly configurable tiling window manager for X. It can be configured with a configuration file, supports Xft (FreeType) fonts and is compliant with the Extended Window Manager Hints (EWMH) specifications, Xinerama and Xrandr. WMFS can be driven with Vi based commands (ViWMFS).|https://github.com/xorg62/wmfs|{{AUR|wmfs}}}}<br />
<br />
* {{App|[[WMFS2]]|Incompatible successor of WMFS. It's even more minimalistic and brings some new stuff.|https://github.com/xorg62/wmfs|{{AUR|wmfs2-git}}}}<br />
<br />
=== Dynamic window managers ===<br />
<br />
* {{App|[[awesome]]|Highly configurable, next generation framework window manager for X. It is very fast, extensible and licensed under the GNU GPLv2 license. Configured in Lua, it has a system tray, information bar, and launcher built in. There are extensions available to it written in Lua. Awesome uses XCB as opposed to Xlib, which may result in a speed increase. Awesome has other features as well, such as an early replacement for notification-daemon, a right-click menu similar to that of the *box window managers, and many other things. |https://awesomewm.org/|{{Pkg|awesome}}}}<br />
<br />
* {{App|[[catwm]]|Small window manager, even simpler than dwm, written in C. Configuration is done by modifying the config.h file and recompiling.|https://github.com/pyknite/catwm|{{AUR|catwm-git}}}}<br />
<br />
* {{App|[[dwm]]|Dynamic window manager for X. It manages windows in tiled, monocle and floating layouts. All of the layouts can be applied dynamically, optimising the environment for the application in use and the task performed. does not include a tray app or automatic launcher, although dmenu integrates well with it, as they are from the same author. It has no text configuration file. Configuration is done entirely by modifying the C source code, and it must be recompiled and restarted each time it is changed.|http://dwm.suckless.org/|{{AUR|dwm}}}}<br />
<br />
* {{App|[[echinus]]|Simple and lightweight tiling and floating window manager for X11. Started as a dwm fork with easier configuration, echinus became full-featured re-parenting window manager with EWMH support. It has an EWMH-compatible panel/taskbar, called {{AUR|ourico}}.|http://plhk.ru|{{AUR|echinus}}}}<br />
<br />
* {{App|[[FrankenWM]]|Basically monsterwm with floating done right. Features that are added on top of basic mwm include: more layouts (fibonacci, equal stack, dual stack), gaps (and borders) are adjustable on the fly, minimize/maximize single windows, hide/show all windows, resizing master and stack individually, invert stack.|https://github.com/sulami/FrankenWM|{{AUR|frankenwm-git}}}}<br />
<br />
* {{App|[[spectrwm]]|Small dynamic tiling window manager for X11, largely inspired by xmonad and dwm. It tries to stay out of the way so that valuable screen real estate can be used for much more important stuff. It has sane defaults and is configured with a text file. It was written by hackers for hackers and it strives to be small, compact and fast. It has a built-in status bar fed from a user-defined script.|https://github.com/conformal/spectrwm/wiki|{{Pkg|spectrwm}}}}<br />
<br />
* {{App|[[Qtile]]|Full-featured, hackable tiling window manager written in Python. Qtile is simple, small, and extensible. It's easy to write your own layouts, widgets, and built-in commands.It is written and configured entirely in Python, which means you can leverage the full power and flexibility of the language to make it fit your needs. |https://github.com/qtile/qtile|{{Pkg|qtile}}}}<br />
<br />
* {{App|[[wmii]]|Small, dynamic window manager for X11. It is scriptable, has a 9P filesystem interface and supports classic and tiling (Acme-like) window management. It aims to maintain a small and clean (read hackable and beautiful) codebase. The default configuration is in bash and [http://rc.cat-v.org rc (the Plan 9 shell)], but programs exist written in ruby, and any program that can work with text can configure it. It has a status bar and launcher built in, and also an optional system tray ({{ic|witray}}). |http://wmii.suckless.org/|{{AUR|wmii}}}}<br />
<br />
* {{App|[[xmonad]]|Dynamically tiling X11 window manager that is written and configured in Haskell. In a normal WM, you spend half your time aligning and searching for windows. Xmonad makes work easier, by automating this. XMonad is configured in Haskell. For all configuration changes, xmonad must be recompiled, so the Haskell compiler (over 100MB) must be installed. A large library called {{Pkg|xmonad-contrib}} provides many additional features|http://xmonad.org/|{{Pkg|xmonad}}}}<br />
<br />
== See also ==<br />
<br />
* http://www.gilesorr.com/wm/<br />
* http://www.slant.co/topics/390/~what-are-the-best-window-managers-for-linux<br />
* https://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-desktops/</div>Exoro