Deutsch | English

Table of contents


Configuration and navigation were adapted from i3. A migration from i3 to Sway, due to a possible shift from X11 to Wayland et vice versa, is therewith possible to a large extent.


Sway is the only compatible Wayland tiling window manager that has found its way into the repos of Fedora and into various other distributions. The website can be found here ⁽¹⁾. Sway was officially introduced in a Phoronix article about 3 years ago ⁽²⁾. The hub and pivotal point is the GitHub repo ⁽³⁾ and there the related Wiki ⁽⁴⁾. As always, the friendly Wiki by Arch Linux ⁽⁵⁾ helps. Useful also the blog of Drew DeVault, the main developer of Sway. The status report provides an overview of implemented functions and the direction of further development ⁽⁶⁾. The thread on Reddit addresses a few more problem cases and is therefore helpful in a preliminary decision ⁽⁷⁾. Furthermore, there is a 1.0 alpha from Sway ⁽⁸⁾, which underlines a certain stability of the project.

  1. Sway → Website
  2. Phoronix → »An i3-Compatible Tiling Window Manager For Wayland«
    Date: 2015-08-18 | Author: Michael Larabel
  3. GitHub: swaywm/sway → »i3-compatible Wayland compositor«
  4. GitHub: swaywm/sway → Wiki: »Home«
  5. Arch Linux: Wiki → »Sway«
  6. Blog: drewdevault → »State of Sway August 2017«
    Date: 2017-08-09 | Author: Drew DeVault
  7. Reddit: unixporn → »(sway) Once you go wayland you never go back«
    Posted: 2017-11-25
  8. GitHub: swaywm/sway → Code: »1.0-alpha.1«
    Released: 2018-04-7 | Releases: v1.0-alpha.1


We take a look at the underlying library and associate the development stations by other libraries.

Wayland Compositor Library

Weston was/is the reference implementation of the Wayland Composer, with its own library called libweston. Weston also interacts with X clients. Is libweston deployed in projects? Experimental at maximum. No relevant compositor in desktop environments uses libweston. This is also not the case with tiling window managers. libweston, Weston and the related desktop are to be understood as reference and as such they are justified ⁽¹⁾. Nonetheless, it is still worthwhile to get an overview and follow the link paths given there at least briefly.

Incidentally, this also applies to wlc. In the camp of tiling window managers, wlc was ultimately the library that was used by default ⁽²⁾. In 2017, Sway has been rebuilt for use with wlroots as a library. The implementation phases can be tracked in GitHub issue #1076 ⁽³⁾. wlroots is not only used by Sway, but meanwhile has connections to other programming languages, ​such as Haskell or Rust, so that the Wayland successors of Awesome and XMonad use this by now or plan to do so. The blog entry “Future of Wayland, and sway's role in it” outlines once more the relationship between wlc and wlroots ⁽⁴⁾. This course of development can be tracked by issue #1390, issue #1076 follows it chronologically and produces wlroots ⁽⁵⁾.

A statement on the state of Nvidia support can be found in the blog entry of 2017-10-26 and should answer questions regarding this ⁽⁶⁾. A PDF to wlroots explains ambitions and differentiation to other libraries ⁽⁷⁾. The GitHub repo can be found here ⁽⁸⁾ and an overview of some bindings to other programming languages ​​can be found at this place ⁽⁹⁾ - whereby a search at GitHub will bring more light on this matter.

  1. GitHub: giucam/weston → »The Weston Wayland Compositor«
  2. GitHub: Cloudef/wlc → »High-level Wayland compositor library«
  3. GitHub: swaywm/sway → »Issues« → »In-house compositor design discussion«
    Opened: 2017-02-15 | Issue: 1076
  4. Blog: drewdevault → »Future of Wayland, and sway's role in it«
    Date: 2017-10-09 | Author: Drew DeVault
  5. GitHub: swaywm/sway → »Issues« → »wlroots status«
    Opened: 2017-10-12 | Issue: 1390
  6. Blog: drewdevault → »Nvidia sucks and I'm sick of it«
    Date: 2017-10-26 | Author: Drew DeVault
  7. PDF → »Modular Wayland compositors with wlroots
    Date: 2017-12-28
  8. GitHub: swaywm/wlroots → »A modular Wayland compositor library«
  9. GitHub: Sway → »SirCmpwn's Wayland Compositor and related projects«

Client-side decorations versus server-side decorations

Sometimes hard discussions arise to alleged trifles, in this case it is about title or header bars. The arguments of the GNOME developers have some evidence. Tobias Bernard illustrates this in his blog post ⁽¹⁾. The definition and design of a header bar is one of the core design patterns and is concretely and vividly defined in the GNOME Developer Guide ⁽²⁾. An overview of applications, where this has to be implemented - according to the GNOME developers - can be found here ⁽³⁾.

This is diametrically opposed by the requirements of the developers of tiling window managers. What consequences client-side decorations can have and what has been done against this is shown in two blog posts. First, a contribution by Drew DeVault, who is responsible for the development of Sway and wlroots ⁽⁴⁾. And secondly, a comment by Martin Flöser, because the KDE camp has a different point of view to this ⁽⁵⁾.

Window decorations are therefore an important element. – let's look at it as a component in this context. For server-side decorations and the deactivation of client-side secorations, an extension from the KDE camp has been integrated into Sway ⁽⁶⁾.

  1. GNOME: Blogs → »Space and Meaning« → »Introducing the CSD Initiative – Let’s get rid of title bars.«
    Date: 2018-01-26 | Author: Tobias Bernard
  2. GNOME: Developer → Design patterns: Core design patterns → »Header bars«
  3. GNOME: Wiki → »Client-Side Decorations Initiative«
    Last edited: 2018-02-22
  4. Blog: drewdevault → »Sway and client side decorations«
    Date: 2017-01-27 | Author: Drew DeVault
  5. Blog: martin-graesslin → »Server side decorations and Wayland«
    Date: 2018-01-27 | Author: Martin Flöser
  6. Phoronix → »Sway 0.14 Supports KDE Server Decorations Protocol, Mouse Button Bindings«
    Date: 2017-07-27 | Author: Michael Larabel


The panel for Sway is currently an integral part of Sway ⁽¹⁾, while other components become separate modules ⁽²⁾. The man page provides information about the configuration and control options ⁽³⁾.

  1. GitHub: swaywm/sway → swaybar
    Date: 2017 | Author: Robert Washbourne
  2. GitHub: swaywm/sway → Issues → »Split swaylock, swaybg into standalone projects«
    Opened: 2018-0501 | Issue: 1875
  3. ManKier: Linux man pages → sway → sway-bar

Issues and Workarounds

The issue tracker for Sway is still the first port of call due to the lack of features. Currently, it is conceivable that a problem is still stuck in the problem-solving pipeline ⁽¹⁾. And since we now know that we are dealing with 2 components, an additional look into the issue tracker of wlroots is necessary in parallel during troubleshooting ⁽²⁾. Anjan Momi explains to us the fine adjustment of several monitors under Sway ⁽³⁾.

  1. GitHub: swaywm/sway → »Issues«
  2. GitHub: swaywm/wlroots → »Issues«
  3. Blog: → »Setup Multiple Monitors in Sway (Wayland)«
    Date: 2016-11-02 | Author: Anjan Momi

Compatibility between Sway and i3

Minor differences in usage and functionality are listed here ⁽¹⁾. Therefore, to make the switch to Sway from i3 smooth, have a look at this ⁽²⁾. Not yet implemented i3 features can be found here ⁽³⁾.

  1. GitHub: swaywm/sway → Wiki → »Differences from i3
  2. GitHub: swaywm/sway → Wiki → »i3 Migration Guide«
  3. GitHub: swaywm/sway → Issues → »i3 feature support #2«

Replacing the window manager of the desktop environments

This is handled very quickly in this case.

Sway and MATE

MATE is currently designed for X11. Components, such as the MATE panel, could possibly be combined with Sway if that happens to change.

Sway and GNOME

The GNOME Shell is a plugin of the window manager Mutter. The panel, the application overview, the Dash - are part of the GNOME Shell. Everything runs in one process. In contrast to the MATE desktop, no independent component is thus integrated into the desktop as a bar. If the compositor Mutter is replaced, individual elements of the GNOME shell can not be easily integrated. Under Wayland, the GNOME desktop can therefore only be used to a very limited extent in conjunction with another window manager. Questions and brief explanations were available at these places ⁽¹⁾ ⁽²⁾. The definitive answer, at least for this time, can be found in the FAQ of Sway ⁽³⁾.

  1. Ubuntu Forums: Desktop environments → »Customize top bar in 17.10«
    Opened: 2017-12-01
  2. Reddit: Fedora → »Does openbox replace the desktop environment«
    Opened: 2018-02-11
  3. GitHub: swaywm/sway → Wiki → »FAQ« → »Can I use Sway with Gnome?«

Creative Commons License
This article is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International License.