Тайлинговые оконные менеджеры в Linux
Обычные пользователи привыкли к тому, что взаимодействие с системой происходит посредством клавиатуры и мыши. Но среди сообщества Linux есть те, кто считает использование мыши чрезмерным и замедляющим пользователя. Потому они всячески призывают работать только с клавиатуры, а в качестве оболочки для взаимодействия использовать тайлинговые оконные менеджеры. Вещь эта интересная, конечно, но не для всех. Ниже расскажу, что такое тайлинг, какие оконные менеджеры популярны и почему я не хочу их использовать.
Что такое оконный менеджер?
Оконные менеджеры представляют собой программу, которая отвечает за отрисовку, положение и поведение окон в системе. Именно оконный менеджер показывает вам окна, позволяют их сворачивать/разворачивать, открывать/закрывать. Каждая среда рабочего стола, про которые мы говорили ранее, имеет свой оконный менеджер.
Например, GNOME с третьей версии имеет оконный менеджер Mutter (до 3 версии оконным менеджером был Metacity), среда KDE предлагает пользователю менеджер окон kwin, XFCE основан на Xfwm4.
При этом большинство популярных сред рабочего стола потребляют определенную часть системных ресурсов, что не всегда подходит пользователям и они, либо выбирают легковесные среды (например, Lxqt или LXDE), либо используют оконные менеджеры без рабочей среды.
Тайлинговые оконные менеджеры
Суть тайлинговых оконных менеджеров состоит в том, что они разбивают рабочее пространство монитора на прямоугольные непересекающиеся области, именуемые фреймами или тайлами (от англ. frame — рамка или tile — плитка). Каждое запускаемое приложение занимает один такой тайл (фрейм), при этом чаще всего у окна отсутствует привычное оформление (заголовок, полоса прокрутки, кнопки для сворачивания/разворачивания и закрытия и пр.).
Пространство, которое занимает приложение, запущенное через тайлинговый менеджер, меньше пространства среды рабочего стола. Навигация между открытыми приложениями осуществляется при помощи клавиатуры, мышь используется редко. Пользователь сам определяет как будут открываться окна с приложениями — на каком экране (если их несколько), на каком участке рабочего пространства и как оно будет себя вести после открытия.
Популярные тайлинговые оконные менеджеры
Многообразие Linux добралось и сюда, потому количество тайлинговых оконных менеджеров огромно. Самыми популярными являются следующие:
Опять-таки, практически каждый популярный дистрибутив имеет сборку с одним или несколькими тайлинговыми оконными менеджерами. Например, такие сборки имеют Manjaro, Fedora. Мы не будем останавливаться на различиях и особенностях каждого менеджера, так как тогда объем информации будет огромен. Если тематика тайлинга вас заинтересует, то каким-то отдельным менеджерам я посвящу ряд статей.
Почему я не использую тайлинговые оконные менеджеры
Главная причина — необходимость конфигурации и тонкой настройки. После установки системы с тайлинговым оконным менеджером вы получаете просто черный экран, без привычных панелей, системного трея, настроенного поведения окон. Это все нужно конфигурировать вручную, затрачивая на это время. Я пробовал некоторые менеджеры (i3 и bspwm), но необходимость искать информацию только для того, чтобы добавить значок Яндекс Диска на панель или настроить работу Bluetooth меня убивает морально. Потому я лучше выберу какую-либо среду рабочего стола и буду использовать ее.
Несомненно, если потратить достаточное количество времени, то можно превратить системы в «конфетку» и в интернете достаточно скриншотов красиво настроенных и функциональных версии дистрибутивов Linux. Расскажите в комментариях, использовали ли вы тайлинговые оконные менеджеры и если да, то какие. Быть может, вы являетесь активным пользователем тайлинга.
Comparison of tiling window managers
This article provides an unbiased comparison of the most popular tiling window managers (as opposed to floating window managers).
Comparison table
The following table lists the most popular tiling window managers alongside notable features, providing readers with a quick overview.
| 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Awesome | 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. Example | Yes | Active |
| bspwm | C | Anything | Hybrid | None | Yes | Can write internal state to a FIFO | External | v-split, h-split | Variable borders | via bspc | XCB | Monitors hold Desktops | Yes | Active |
| dwm | C | C (recompile) | Dynamic | Optional Patch | Optional | Built-in, reads from root window name | External | v-stack, max | via dwmfifo | Xlib | n regions, 9 workspaces fixed to each region | No | Active | |
| FrankenWM | 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 | No | Active | ||
| herbstluftwm | C++ | Anything | Manual | None | Yes | External | vertical, horizontal, grid, max, tabbed | 1-pix borders | commands via herbstclient | Xlib | n regions, 9 workspaces visible in any region | Yes | Active | |
| i3 | C | Text | Manual | i3bar | Yes (Layout is preserved) | text piped to i3bar ( i3status / 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 |
| LeftWM | Rust | RON (user settings) / Anything (themes) | Dynamic | None | Yes | Yes, many options through theme system | External | v-stack, columns, rows | Variable based on theme | supports _NET_ACTIVE_WINDOW and sending commands to a named pipe | Xlib | Workspaces and monitors are not tied. Many workspaces for monitor or many monitors for workspace | Yes | Active |
| Notion | 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 | |
| qtile | Python | Python | Dynamic | Yes | Yes | Yes | External | tree, v-split, h-split, stacked, tabbed, max | No borders, although customizable | Hooks, Server mode | XCB | Active | ||
| Ratpoison | C | Text | Manual | None | Yes | Yes | External | max | No | Active | ||||
| Snapwm | 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 | ||
| Spectrwm | 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 | No | Active | |
| Stumpwm | Common Lisp | Common Lisp | Manual | StumpTray | Yes | Yes | External | max | SLIME server («Swank») | Xlib | No | Active | ||
| xmonad | Haskell | Haskell | Dynamic | None | Yes | No | Yes, with xmonad-contrib and an external manager | nv-stack, nh-stack, max | Variable borders, no titles | via XMonad-Hooks-ServerMode | Xlib | n regions, 9 workspaces visible in any region | Yes / via XMonad-Hooks-EwmhDesktops | Active |
| 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 |
Tip: External control can also be achieved by programs like xdotool which simulate keystrokes.
Management style
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.
Layouts
A number of common layout types appear in several tiling WMs, although the terminology varies somewhat.
- max: one window shown fullscreen (with or without a status bar, title and borders). Aka: monocle (dwm, monsterwm).
- 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).
- 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).
- nh-stack: h-stack allowing >=1 windows in master area. Aka: nbstack (dwm)
- nv-stack: v-stack allowing >=1 windows in master area. Aka: ntile (dwm)
- mirror-h: nh-stack with stacks above and below the master area
- mirror-v: nv-stack with stacks to the left and right of the master area
- h-tab: one window shown fullscreen with all window titles shown horizontally (like browser tabs)
- v-tab: one window shown fullscreen with all window titles shown vertically. Aka: stack (wmii).
- h-split: a keybinding splits the current window horizontally creating space for another
- v-split: a keybinding splits the current window vertically creating space for another
- columns: manual layout style which treats windows as belonging to vertical columns
- rows: manual layout style which treats windows as belonging to horizontal rows
- grid: window positions and sizes based on a regular NxM grid. May be automatic (like wmfs, monsterwm) or manual (like Subtle).
Key bindings
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.