Deutsch | English

Inhalt


Sway

Konfiguration und Steuerung wurden von i3 adaptiert. Eine Migration von i3 nach Sway, bedingt durch einen möglichen Wechsel von X11 zu Wayland et vice versa, ist damit weitgehend reibungslos möglich.

Sway

Sway hat als einziger Wayland-kompatibler Tiling-Window-Manager seinen Einzug in die Repos von Fedora gefunden und auch in viele andere Distributionen. Die Website findet sich hier ⁽¹⁾. Sway wurde vor knapp 3 Jahren in einem Phoronix-Artikel offiziell vorgestellt ⁽²⁾. Dreh- und Angelpunkt ist das GitHub-Repo ⁽³⁾ und das dortige Wiki ⁽⁴⁾. Wie immer, hilft auch das freundliche Wiki von Arch Linux ⁽⁵⁾. Nützlich auch der Blog von Drew DeVault, des Hauptentwicklers von Sway. Der Statusbericht verschafft einen Überblick über implementierte Funktionen und die Richtung bei der weiteren Entwicklung ⁽⁶⁾. Der Thread auf Reddit spricht noch einmal einige Problemfälle an und ist somit nochmal hilfreich bei einer Vorentscheidung ⁽⁷⁾. Des Weiteren gibt es seit kurzem eine 1.0 alpha von Sway ⁽⁸⁾, was eine gewisse Stabilität des Projektes noch einmal mit untermauert.

  1. Sway → Website
  2. Phoronix → »An i3-Compatible Tiling Window Manager For Wayland«
    Datum: 2015-08-18 | Autor: 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«
    Datum: 2017-08-09 | Autor: Drew DeVault
  7. Reddit: unixporn → »(sway) Once you go wayland you never go back«
    Gepostet: 2017-11-25
  8. GitHub: swaywm/sway → Code: »1.0-alpha.1«
    Veröffentlicht: 2018-04-7 | Releases: v1.0-alpha.1

Komponenten

Wir schauen uns einmal die zugrundeliegende Bibliothek an und ordnen die Entwicklungsstationen über andere Bibliotheken zu.

Wayland Compositor Bibliothek

Weston war/ist die Referenzimplementierung des Wayland-Compositors, mit einer eigenen Bibliothek namens libweston. Weston interagiert auch mit X-Clients. Wird libweston in Projekten eingesetzt? Maximal experimentell. Kein relevanter Compositor in Desktop-Umgebungen greift auf libweston zurück. Auch bei den Tiling-Window-Managern ist dies nicht der Fall. libweston, Weston und der zugehörige Desktop sind als Referenz zu verstehen und haben als solche ihre Berechtigung ⁽¹⁾. Es lohnt sich dennoch, sich einen Überblick zu verschaffen und auch den dort angegeben Linkpfaden wenigstens kurz zu folgen.

Dies gilt übrigens auch für wlc. Im Lager der Tiling-Window-Manager war wlc letztendlich die Bibliothek, die standardmäßig eingesetzt wurde ⁽²⁾. 2017 wurde Sway für die Verwendung mit wlroots als Bibliothek umgebaut. Im GitHub Issue #1076 lassen sich die Implemetierungphasen nachverfolgen ⁽³⁾. wlroots wird nicht nur von Sway verwendet, sondern bringt mittlerweile Anbindungen an andere Programmiersprachen wie Haskell oder Rust mit, so dass auch die Wayland-Nachfolger von Awesome und XMonad diese mittlerweile verwenden oder dies planen. Der Blogeintrag »Future of Wayland, and sway's role in it« erläutert noch einmal den Zusammenhang zwischen wlc und wlroots ⁽⁴⁾. Nachverfolgen lässt sich dieser Entwicklungsverlauf anhand Issue #1390, Issue #1076 schließt chronologisch daran an und bringt wlroots hervor ⁽⁵⁾.

Ein Statement zum Zustand der Nvidia-Unterstützung findet sich im Blogeintrag vom 2017-10-26 und dürfte Fragen diesbezüglich beantworten ⁽⁶⁾. Ein PDF zu wlroots erläutert Ambitionen und Abgrenzung zu anderen Bibliotheken ⁽⁷⁾. Das GitHub-Repo findet sich hier ⁽⁸⁾ und ein Überblick über einige Anbindungen zu anderen Programmiersprachen findet sich an dieser Stelle ⁽⁹⁾ – wobei eine Suche bei GitHub diesbezüglich noch mehr zu Tage fördern wird.

  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«
    Eröffnet: 2017-02-15 | Issue: 1076
  4. Blog: drewdevault → »Future of Wayland, and sway's role in it«
    Datum: 2017-10-09 | Autor: Drew DeVault
  5. GitHub: swaywm/sway → »Issues« → »wlroots status«
    Eröffnet: 2017-10-12 | Issue: 1390
  6. Blog: drewdevault → »Nvidia sucks and I'm sick of it«
    Datum: 2017-10-26 | Autor: Drew DeVault
  7. PDF → »Modular Wayland compositors with wlroots
    Datum: 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

Um vermeintliche Petitessen entstehen manchmal harte Diskussionen, in diesem Fall um Titel- oder Kopfleisten. Die Argumente der GNOME-Entwickler haben einiges für sich. Tobias Bernard veranschaulicht dies in seinem Blogbeitrag ⁽¹⁾. Die Definition und Konzeption einer Kopfleiste gehört zu den Core-Design-Patterns und wird im GNOME Developer Guide konkret und anschaulich definiert ⁽²⁾. Eine Übersicht von Applikationen, bei denen dies implementiert werden soll – nach Vorstellung der GNOME-Entwickler – findet sich hier ⁽³⁾.

Dem stehen diametral die Anforderungen der Entwickler von Tiling-Window-Managern entgegen. Welche Folgen Client-Side-Decorations haben können und was man dagegen getan hat ist zwei Blogbeiträgen zu entnehmen. Zum einen ein Beitrag von Drew DeVault, der für die Entwicklung von Sway und wlroots verantwortlich ist ⁽⁴⁾. Und zum anderen ein Kommentar von Martin Flöser, denn das KDE-Lager hat hierzu einen anderen Standpunkt ⁽⁵⁾.

Fensterdekorationen sind somit ein wichtiges Element – betrachten wir es in diesem Kontext als Komponente. Für Server-Side-Decorations und die Deaktivierung von Client-Side-Decorations wurde eine Erweiterung aus dem KDE-Lager in Sway integriert ⁽⁶⁾.

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

Panel

Das Panel für Sway ist derzeit integraler Bestandteil von Sway ⁽¹⁾, während andere Komponenten separate Module werden ⁽²⁾. Die Man-page informiert über die Konfigurations- und Steuerungsmöglichkeiten ⁽³⁾.

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

Issues und Workarounds

Der Issue-Tracker für Sway ist, aufgrund noch fehlender Features, die erste Anlaufstelle. Aktuell ist es denkbar, dass ein Problem schlichtweg noch in der Problemlösungs-Pipeline fest hängt ⁽¹⁾. Und da wir nun wissen, dass wir mit 2 Komponenten agieren, ist ein zusätzlicher Blick in die den Issue-Tracker von wlroots parallel bei der Fehlersuche notwendig ⁽²⁾. Die Feinjustierung mehrerer Monitore unter Sway erklärt uns Anjan Momi ⁽³⁾.

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

Kompatibilität zwischen Sway und i3

Kleinere Unterschiede in der Handhabung und Funktionalität sind hier aufgelistet ⁽¹⁾. Damit der Wechsel auf Sway von i3 sanft verläuft, schaut man hier ⁽²⁾. Noch nicht implementierte i3-Features finden sich hier ⁽³⁾.

  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«

Austausch des Fenstermanagers der Desktop-Umgebungen

Das ist sehr schnell abgehandelt in diesem Fall.

Sway und MATE

MATE ist aktuell für X11 ausgelegt. Komponenten, wie das MATE-Panel, könnten – sofern sich dies einmal ändert – unter Umständen durchaus mit Sway kombiniert werden.

Sway und GNOME

Die GNOME Shell ist ein Plugin des Fenstermanagers Mutter. Das Panel, die Übersicht über die Applikationen, die Dash – sind wiederum Teile der GNOME Shell. Alles läuft in einem Prozess. Im Gegensatz zum MATE-Desktop, wird hier somit keine eigenständige Komponente als Leiste in den Desktop integriert. Wird der Compositor Mutter ausgetauscht, können einzelne Elemente der GNOME Shell nicht ohne weiteres integriert werden. Unter Wayland kann der GNOME-Desktop somit nur sehr eingeschränkt verwendet werden im Zusammenspiel mit einem anderen Fenstermanager. Rückfragen und kurze Erläuterungen dazu, gab es an diesen Stellen ⁽¹⁾ ⁽²⁾. Die defintive Antwort, zumindest für diesen Zeitpunkt, findet man in der FAQ von Sway  ⁽³⁾.

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

Creative Commons Lizenzvertrag
Dieser Artikel ist lizenziert unter einer
Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.