Vor acht Jahren wurde im Bugtracker von Mozilla ein Bug eröffnet mit dem Bestreben, Firefox für Linux auf Wayland zu portieren. Doch dann wurde Firefox über Jahre an der Basis umgebaut. Soeben gab Mozilla-Mitarbeiter Mike Hommey, der auch Debian-Maintainer für Firefox ist, bekannt, dass Firefox Nighlies für Linux ab sofort mit Wayland-Unterstützung ausgeliefert werden. Das gilt ab der Version Firefox Nightly vom 15.11. Anwender konnten Firefox auch bisher bereits mit Wayland-Unterstützung bauen und Fedora bietet den Browser schon länger für Wayland an. Die von Mozilla bisher ausgelieferten Nightlies setzten in einer Wayland-Sitzung allerdings noch auf XWayland.
Noch experimentell
Da die Unterstützung für den Nachfolger von X11 noch experimentell ist, ist sie noch nicht standardmäßig aktiviert und muss erst freigeschaltet werden. Dazu muss in einer Wayland-Sitzung die Umgebungsvariable GDK_BACKEND=wayland in /etc/environment oder der ~/.bashrc eingetragen werden. Nach dem sourcen der entsprechenden Datei kannst Du testen, ob das erfolgreich war, indem Du in about:support überprüfst, ob bei WebGL 1 Driver WSI Info oder WebGL 2 Driver WSI Info anstatt GLX jetzt EGL steht. Ein Bugreport von Hommey soll eine einfachere Möglichkeit der Überprüfung anregen.
Bei Chromium auch noch Alpha
Es ist wahrscheinlich noch ein langer Weg, bis Firefox den Wayland-Support standardmäßig aktiviert, aber laut Hommey wurde hiermit ein wichtiger Meilenstein erreicht. Auch Google arbeitet schon lange an Wayland-Unterstützung für Chromium. Erstmals taucht die Absicht in einem Bugreport eines Entwicklers im Jahr 2011 auf. Auch hier ist die Portierung noch nicht über das Alpha-Stadium hinausgekommen. Die Hauptarbeit leistet hier seit Jahren nicht etwa Google, sondern Intel und das galizische Consulting-Unternehmen Igalia. Die Galizier haben den Stand der Entwicklung auf einem Vortrag auf der FOSDEM im Januar 2018 vorgestellt, die Folien stehen zum Download bereit.
In der Fedora-Experimentierküche brodeln zu jeder Zeit interessante Entwicklungen. Red-Hat-Mitarbeiter Christian Schaller berichtet in unregelmäßigen Abständen über solche Entwicklungen, die dann in absehbarer Zeit in Fedora Workstation verfügbar sein werden. Jetzt bietet die kürzlich zu Ende gegangene GNOME-Entwicklerkonferenz GUADEC den Anlass für Schaller, einen neuen Bericht zu veröffentlichen.
Wayland im Hintergrund
Bei den meisten derzeitigen Projekten steht Wayland im Hintergrund. So etwa auch bei Remote Desktop und Desktop-Sharing. Hier stellen Unterschiede von X11 zum von Fedora Workstation seit einigen Veröffentlichungen als Standard eingesetzten Wayland-Protokoll die Entwickler vor neue Herausforderungen.
Entfernte Desktops laden
Jonas Ådahl arbeitet derzeit an Remote-Desktop für die GNOME-Shell. Die für Ende Oktober erwartete Veröffentlichung von Fedora 29 Workstation soll eine VNC-basierte Implementierung des Remote-Desktop bieten, weitere Protokolle wie etwa Spice sollen folgen. VNC ist zwar ziemlich veraltet, ist trotzdem noch recht weit verbreitet und anspruchslos im Einsatz. Um die Wayland-Sitzung über VNC zu teilen kommt das Multimedia-Framework PipeWire zum Einsatz, das vom GStreamer-Pionier Wim Taymans entwickelt wird.
Desktop-Sharing per WebRTC
Jan Grulich, Tomas Popela und Eike Rathke arbeiten seit geraumer Zeit am Desktop-Sharing unter Wayland mit Firefox und Chromium unter Zuhilfenahme von WebRTC. Auch hier spielt PipeWire das Bindeglied, indem die Browser jeweils ein PipeWire-Backend erhalten. Eine gepatchte Firefox-Version steht bereits seit einiger Zeit zum Testen für Fedora 28 und Fedora Rawhide bereit.
PipeWire
Auf der GUADEC 2017 hielt Entwickler Wim Taymans einen Vortrag über die Ideen hinter und den Entwicklungsstand von PipeWire. Hier wird unter anderem beständig an der Nachbildung der Funktionalität des professionellen Audio-Servers Jack gearbeitet. Die Player Totem und Rhythmbox können zum Abspielen von Audio über PipeWire mit dem PulseAudio-GStreamer-Plugin genutzt werden, nachdem ein Ersatz für die libpulse.so implementiert wurde.
Im Herbst wird ein PipeWire und Linux Audio Hackfest stattfinden, bei dem die Teams von PipeWire, GStreamer, Totem, GNOME Control Center, PulseAudio und Jack über die weitere Entwicklung von PipeWire diskutieren.
GNOME Builder im Container
GNOME Builder, die integrierte Entwicklungsumgebung, die seit einiger Zeit in den GNOME-Desktop integriert ist, wird maßgeblich von Christian Hergert entwickelt. Die derzeitige Entwicklung geht in Richtung Unterstützung für die Entwicklung hin zu Embedded-Geräten wie dem kommenden Linux-Smartphone Purism 5. Christian erwähnte zudem in seinem GUADEC-Vortrag, dass Builder wahrscheinlich die erste »Container Native IDE« der Welt ist, indem es einerseits mit dem Ziel entwickelt wird, als Flatpak verteilt zu werden, als auch, Flatpaks als primäres Ausgabeformat zu erstellen.
Bereits im März berichteten wir über die Bemühungen von Red-Hat-Entwickler Jan Grulich, Screensharing für KDE-Plasma unter Wayland zu realisieren. Da Wayland im Gegensatz zu X11 kein Netzwerkprotokoll ist, müssen für das Screensharing unter Wayland neue Wege gefunden werden. Dafür hatte Grulich bereits Backends in Form von xdg-desktop-portal und xdg-desktop-portal-[kde/gtk] für KDE-Plasma und die GNOME-Shell geschrieben und das Audio-Video-Framwork PipeWire zum Streamen auserkoren. Was fehlte, war eine Anwendung, mit der ein User Screensharing auch nutzen konnte.
WebRTC als Screensharing-Anwendung
Seit einigen Wochen arbeitet Grulich mit zwei Kollegen, daran, für diese Aufgabe die in Browsern verwendete Videochat-Technik WebRTC nutzbar zu machen, wie er jetzt in seinem Blog berichtet. WebRTC verwendet eine Klasse namens DesktopCapturer, die sowohl unter X11 als auch den Gegenstücken bei Windows oder macOS Verwendung findet. Diese Klasse hat das Team nun für Wayland aufgebohrt.
Alle Bauteile zusammen
Die Umsetzung dieser Idee unter Verwendung der Portals für Plasma und GNOME sowie PipeWire als Streaming-Agent konnte relativ einfach umgesetzt werden. Dank der Backend-Portals wird diese Technik auch in Sandboxen in Flatpak oder Snap funktionieren. Allerdings müssen die leicht unterschiedlichen Herangehensweisen der Browser an WebRTC noch angepasst werden, bevor der Code produktiv genutzt werden kann. Für Neugierige hat Grulich für Fedora ein Repository aufgesetzt, dass einen Firefox mit den entsprechenden Änderungen enthält. Voraussetzung ist lediglich ein funktionierendes PipeWire.
Screensharing unter Wayland
Ein zweiter Blogeintrag von Grulich geht in die Praxis und erläutert schrittweise, wie Screensharing mit Wayland bereits jetzt auch außerhalb von Fedora genutzt werden kann. Wird der Plasma-Desktop verwendet, so wird hier Version 5.13.2 vorausgesetzt. Sowohl die GNOME-Shell als auch Plasma brauchen noch ein wenig Anpassung, wie Grulich erläutert. Der Blogeintrag bietet zudem für Interessierte am Ende einige Verweise, die das grundlegende Verständnis der verwendeten Techniken vertiefen sollen.
Ein generelles Defizit von Wayland ist das Fehlen von Netzwerktransparenz. Diese aus Sicherheitserwägungen fehlende Funktionalität bedeutet, dass das Wayland-Protokoll keine Lösung für etablierte Techniken wie Screen-Recording und -Sharing mitbringt. Diese Funktionalität muss bei Wayland über die Compositoren gegeben sein. Fedora- und KDE-Entwickler Jan Grulich arbeitet an der Bereitstellung dieser Funktionalität unter Plasma. Hierbei kommt neben einer neuen API auch das neue Multimedia-Framework Pipewire ins Spiel.
API für Wayland Screen-Sharing
Eine der Gründe für die Entwicklung von Pipewire war die Unterstützung von gewohnter Funktionalität, die unter anderem bei Flatpak und Wayland aus Sicherheitsaspekten einem neuen Ansatz folgen muss. Die benötigte API für Screen-Recording und -Sharing und Remote-Desktop wurde unlängst in das xdg-desktop-portal eingefügt. Mit Hilfe dieser API können Anwendungen nun auf Ihren Bildschirminhalt in Wayland-Sitzungen oder in Sandboxen wie bei Flatpak zugreifen.
Mit verschiedenen Backend-Implementierungen wie xdg-desktop-portal-kde oder xdg-desktop-portal-gtk muss nur eine einzige API unterstützt werden, um alle Desktops anzusprechen. Das Screen-Cast-Portal beispielsweise funktioniert so, dass der Client zunächst eine Sitzung mit der Backend-Implementierung des xdg-desktop-portal (xdp) erstellt.
Pipewire liefert den Stream
Der Benutzer erhält dann einen Dialog zur Freigabe des Bildschirms, den er freigeben möchte und startet damit die Bildschirmfreigabe. Sobald er das getan hat, erstellt die xdp-Backend-Implementierung einen Pipewire-Stream, sendet die Antwort an den Client mit Stream-ID zurück und der Client kann sich mit dieser ID mit dem Stream verbinden und seinen Inhalt abrufen.
Grulich hat vor wenigen Tagen die Unterstützung für das Screen-Cast-Portal für das xdg-desktop-portal-kde in den KDE-Phabricator eingebracht und wartert derzeit auf das Ergebnis des Reviews. Er hofft, der Code könne früh genug für Plasma 5.13 freigegeben werden, dessen Veröffentlichung für den 12. Juni geplant ist.
Fedora 27 lieferte erstmals das neue Multimedia-Framework PipeWire aus. Die Anwendung soll für Audio und Video das leisten, was heute PulseAudio heute für Audio zu bieten hat. Darüber hinaus sollen auch professionelle Szenarien unter Einbeziehung des Soundservers Jack abgedeckt werden, die über die Funktionalität von PulseAudio hinausgehen. Begonnen hat die Entwicklung bereits vor einigen Jahren.
GStreamer als Vorbild
Entwickler Wim Taymans, der für Red Hat arbeitet, hatte bereits bei der Entwicklung von GStreamer federführend mitgearbeitet. Mit dem Aufkommen des alternativen Paketmodells Flatpak suchte er nach einer Möglichkeit, diesen Desktop-Containern – denn nichts anderes ist Flatpak – die Soundausgabe per PulseAudio zu ermöglichen. Im Anschluss begann er die Arbeit an PulseVideo, um das Gleiche auch für Bewegtbilder umzusetzen.
Im Endeffekt fiel die Entscheidung, Audio und Video in einem Framework zu bündeln, das den Namen PipeWire erhielt. Jetzt hat Red-Hat-Kollege Christian Schaller die gerade stattfindende Fedora-Entwicklerkonferenz DevConf 2018 im tschechischen Brno zum Anlass genommen, anlässlich eines Gesprächs mit Wim Taymans über die Fortschritte bei PipeWire in seinem Blog zu berichten.
Flatpak und Wayland profitieren
Mittlerweile sind es nicht nur mehr Flatpak oder Container im Allgemeinen, die auf ein modernes Framework angewiesen sind, um den Zwängen einer Sandbox gerecht zu werden und containerisierten Anwendungen die Ausgabe von Audio und Video über den Host trotzt Restriktionen zu ermöglichen. Auch Wayland braucht im Bereich Multimedia neue Lösungen, will es die Funktionalität von Xorg besser abdecken.
Das Anzeige-Protokoll Wayland ist mit mehr Augenmerk auf Sicherheit konzipiert als das rund 30 Jahre alte Netzwerkprotokoll X11. Aus diesem Grund wurde auch standardmäßig keine Netzwerktransparenz implementiert. Das bedeutet, dass das Wayland-Protokoll von Hause aus heute selbstverständliche Dinge wie Screensharing und -recording oder Remote Desktop per RDP oder VNC nicht unterstützt. Es gibt Anstrengungen, auch für Oberflächen von Wayland-Anwendungen die Verwendung über das Netzwerk zu realisieren. Eine davon nennt sich Waltham und wird bei Collabora entwickelt. Hier geht es aber in erster Linie vorerst nicht um den Desktop, sondern um den Automobilbereich.
Screensharing und Remote Desktop
Eine weitere Entwicklung in diese Richtung, die wiederum PipeWire ins Spiel bringt, wird von Red Hats Jonas Ådahl vorangetrieben und soll diese Funktionalität für GNOME zurückbringen. Da die Funktion im Compositor verankert ist, wird sie auch von anderen Desktop-Umgebungen nutzbar sein, die Wayland einsetzen. Das ist zwar alles noch im experimentellen Stadium, aber PipeWire beherrscht bereits rudimentär das Teilen von Geräten, wie Entwickler Taymans am Beispiel der Videoanwendung Cheese und PipeWire im Terminal demonstrierte. Zwei Anwendungen teilen sich dabei eine Webcam ohne sich gegenseitig zu stören. Dabei kommt ein PipeWire-GStreamer-Plugin zum Einsatz, was die Anpassung an die jeweilige Anwendung übernimmt.
Als Nächstes soll PipeWire zeitnah an Firefox und Chrome angepasst werden um Konferenzsoftware damit unter Wayland lauffähig zu bekommen. Der Sound-Server Jack für professionelle Ansprüche wie etwa geringe Latenzen wurde mittlerweile als Protokoll auf PipeWire draufgesetzt, sodass kein extra Jack-Server mehr vonnöten ist. Auf der Cosumer-Seite ist Bluetooth-Untzerstützung gegeben, wobei ein PipeWire-Bluetooth-Modul sich direkt mit dem Bluez-Bluetooth-Framework verbindet.
Aussichten
PulseAudio-Applikationen sollen nach den Plänen der Entwickler zunächst Sound über PipeWire ausgeben. Für GStreamer-Apps stellt sich die Frage nicht, da sie nativ PipeWire nutzen. Für Apps, die noch ALSA verlangen, soll es ein PipeWire-ALSA-Layer geben so wie es jetzt ein PulseAudio-ALSA-Layer gibt. PulseAudio soll im späteren Verlauf einmal überflüssig werden, was jedoch einige Jahre dauern wird. Für das im Mai anstehende Fedora 28 soll zumindest der Video-Part ausgeliefert werden, weitere Schritte sollen mit den nächsten Veröffentlichungen folgen.
Vor einem knappen Monat erschien im 21. Jahr des Bestehens des Projekts die Beta-Version von KDE Plasma 5.11, jetzt wurde die stabile Version freigegeben. Über viele der Neuheiten haben wird bereits damals berichtet. Darüber hinaus wurde die Integration von Wayland weiter vorangetrieben. Ein ressourcenschonendes Ergebnis der anhaltenden Implementierung des neuen Display-Servers ist, dass Plasma 5.11 komplett ohne die Kompatibilitätsschicht XWayland genutzt werden kann. Diese nur noch bei Bedarf gestartet. Zudem skalieren Fenster unter Wayland jetzt abhängig von der Pixeldichte des Displays. Das hilft in Umgebungen mit mehreren Monitoren bei unterschiedlichen Auflösungen. Alle weiteren Änderungen sind in den offiziellen Release-Notes nachzulesen. Plasma 5.11 ist bereits bei KDE Neon und openSUSE verfügbar.
Plasma 5.12 in Planung
Derweil wird bereits die Marschrichtung für Plasma 5.12 ausgegeben, das im Januar 2018 zur Veröffentlichung ansteht. Plasma-Entwickler Martin Flöser (früher Gräßlin) rief auf der Plasma-Entwicklerliste dazu auf, die Wayland-Implementierung für 5.12 zu forcieren. Dazu sollen alle Entwickler möglichst oft Wayland im Alltag nutzen und auch die Entwicklungsarbeit unter Verwendung des neuen Display-Servers vorzunehmen. Er habe in letzter Zeit mehrere Screenshots von Entwicklern gesehen, die unter X aufgenommen wurden, so Flöser.
Entwickler sollen mehr Wayland nutzen
So etwas sehe er ungern, das sei enttäuschend, so der Entwickler. Plasma-Entwickler sollten zeigen, dass sie auf Wayland setzen. Nur so würden Fehler entdeckt und könnten beseitigt werden, damit Plasma 5.12 ein großartiges Release werde. Auf jeden Fall wird 5.12 ein langzeitunterstütztes LTS-Release und somit ein gutes Ziel für eine konzertierte Aktion zur Verbesserung der Wayland-Implementierung. Dass es noch genug zu tun gibt, beweist eine Antwort von Entwickler Marco Martin, der angibt, sein Notebook blinke unter Wayland mit einigen Apps wie etwa Dolphin wie eine Disco-Kugel.
Wayland wird künftig immer mehr die Rolle des veralteten X11 übernehmen. Doch längst nicht alle Applikationen sind bereits für Wayland vorbereitet. So werden uns trotzt Wayland als künftigem Standard X11 und die Kompatibilitätsschicht XWayland noch über Jahre begleiten. Während GNOME bereits unter Fedora 26 und bald unter Ubuntu 17.10 mit Wayland als Standard läuft, sind bei KDE die Umbauarbeiten noch im Gange.
KWin-Maintainer Martin Gräßlin stellt jetzt in seinem Blog das XFree-KWin-Projekt vor. Die Idee dahinter ist, KWin unter Wayland ohne XWayland-Unterstützung starten zu können. Während die meisten der dafür notwendigen Änderungen bereits in Plasma 5.11 eingeflossen sind, ist nicht alles rechtzeitig fertig geworden. Jetzt sind die ausstehenden Änderungen im KDE Phabricator zur Überprüfung eingestellt worden. Dabei stellt sich die Frage, warum Zeit damit verbracht wird, KWin ohne X11-Unterstützung zum Laufen zu bringen, wenn XWayland in absehbarer Zukunft trotzdem bereitgestellt werden muss, um Legacy-Anwendungen zu unterstützen, die noch nicht unter Wayland laufen.
Einerseits zeigt es, dass alles portiert ist oder zumindest nicht mehr so stark von X11 abhängt. Dann ist da noch Plasma Mobile, das völlig ohne XWayland auskommt. Durch den Verzicht auf XWayland kann dort der Start beschleunigt und der Speicher entlastet werden. KWin muss beim Start nicht auf XWayland warten, beide können parallel gestartet werden. Das bedeutet KWin und die komplette Plasma-Sitzung startet etwas schneller.
Etwas Hintergrund
Die allgemeine Idee hinter dem Projekt XFree-KWin ist, das Code, der nicht geladen ist auch nicht stören kann. KWin verwendet für die verschiedenen Plattformen auf denen es laufen kann nicht die Qt Platform Abstraction-Plugins sondern separate Plugins pro Plattform. Für KWin unter X11 gibt es ein solches Plattform-Plugin, sodass Code, der nur im KWin/X11-Kontext benötigt wird, in das Plattform-Plugin verschoben werden kann. Da KWin unter Wayland dieses Plugin nicht lädt, wird der Code auch nicht geladen.
Plugin-basierte Compositoren
Eine weitere Idee ist es, Compositoren in Plugins zu integrieren. Insbesondere der auf XRender basierende Compositor ist in einer Wayland-Umgebung unnötig und sollte daher nicht in die Binärdatei geladen werden. Leider haben verschiedene Teile von KWin direkt die konkreten Compositor-Implementierungen aufgerufen, sodass die interne API an dieser Stelle erweitert werden musste. In Plasma 5.11 werden nun der XRender- und QPainter- Compositor als Plugins geladen, sodass bei Wayland der nicht kompatible XRender-Compositor nicht mehr in den Speicher geladen wird – desgleichen bei X11 der nicht kompatible QPainter-Compositor. Aber auch auf Wayland wird der QPainter-Compositor nur dann in den Speicher geladen, wenn er auch verwendet werden soll. Der OpenGL-Compositor wird derzeit noch in Plasma 5.11 geladen, aber die Änderung zur Auslagerung als Plugin ist bereits vorbereitet. Dies bringt große Vorteile für die Stabilität des Systems
Ausblick
KWin unter Wayland ohne X11-Unterstützung zu starten und zu betreiben ist aber erst der Anfang, weitere Änderungen sind erforderlich. So soll das Laden von XWayland in Zukunft generell verzögert werden, bis eine Anwendung versucht, sich damit zu verbinden. Dies wäre beim Start von Plasma derzeit wenig sinnvoll, da Anwendungen wie Ksmerver im Startup noch X11 benötigen.
Ein weiteres recht aufwendiges Projekt ist es, KWin ohne X11-Unterstützung kompilieren zu lassen und alles, was für Xwayland benötigt wird, in ein Plugin auszulagern. Hier muss viel Code bewegt werden und weitere Abstraktionen müssen in einigen Bereichen von KWin hinzugefügt werden. Als schnellen Workaround für Plasma Mobile und das Purism Librem-5-Smartphone könnte laut Flöser ein ifdef um jeden X11-Code-Bereich herum eine vorläufige Lösung sein.
Nachdem erst vor wenigen Tagen die erste Alpha-Version des Debian Installers für Debian 10 Buster vorgestellt wurde, fiel jetzt einem Leser der Webseite Phoronix auf, dass bereits seit einem Monat für Debian Unstable und Testing Wayland als Standardsitzung für den Display-Manager voreingestellt ist.
Am 6. August hatte Jeremy Bicha, der einst Ubuntu GNOME ins Leben gerufen hatte, das Paket gnome-session 3.24.1-1 nach Debian Unstable hochgeladen. Dort steht die unscheinbare Zeile * debian/rules: Switch default "gnome" session to wayland , die den Umstieg von Debian auf das neue Display-Protokoll Wayland einleiten. Somit sind die Weichen gestellt, dass die nächste Debian-Version mit der Versionsnummer 10 und dem Codenamen Buster zumindest in der Standardausführung mit GNOME als Desktop automatisch mit Wayland startet.
X11 geht langsam in Rente
Damit geht die Ära des 1984 am MIT in Boston entwickelten X Window System dem verdienten Ende entgegen. Schon lange ist X11 nicht mehr zeitgemäß. Es ist heute ein schwer wartbarer Flickenterppich aus Patches, die wiederum mit Patches versehen sind. Das heißt aber nicht, dass der X.org-Server damit in der Versenkung verschwinden wird, er wird uns vielmehr noch einige Jahre als Rückfalllösung erhalten bleiben. So wird er auch bei Debian 10 Buster als Alternative vorinstalliert sein.
Wayland als Standard für Debian 10 Buster
Das Wayland-Protokoll, das seit rund zehn Jahren entwickelt wird, beginnt langsam, in den Linux-Distributionen Fuß zu fassen. Fedora 25 hat als Vorreiter Wayland vor rund einem Jahr zum Standard erhoben. In wenigen Wochen wird auch Ubuntu mit 17.10 den Schalter umlegen. Dabei hatte Canonical zunächwst Wayland veteufelt und mit Mir einen Sonderweg eingeschlagen. Diesen gab das Ubuntu-Unternehmen dann im Frühjahr wieder auf.
Bei Debian dauert es mit Wayland in der stabilen Ausgabe der Distribution noch etwas, denn Debian 10 Buster erscheint nicht vor 2019. Anwender der Zweige Testing und Unstable mit GNOME Shell 3.24 arbeiten allerdings bereits jetzt mit Wayland.
In weniger als zwei Wochen, am 13. September erscheint GNOME 3.26. Canonical will diese Version noch vor Fedora 27 als Desktop von Ubuntu 17.10 am 19. Oktober veröffentlichen.
Ubuntu 17.10 »Artful Aardvark« ist eines der wirklich wichtigen Releases in der Geschichte der Distribution. Doch auch für das GNOME-Projekt ist dies ein Meilenstein, denn mit der Veröffentlichung von Ubuntu 17.10 vergrößert sich die Gemeinde der GNOME-Anwender nicht unwesentlich. GNOME war bis zu Ubuntu 10.04 bereits einmal der Standard-Desktop von Ubuntu und wurde dann mit 10.10 von der Eigenentwicklung Unity abgelöst. Diese wiederum wird am 19. Oktober Platz für GNOME 3.26 als zukünftigen Platzhirsch in der Ubuntu-Familie machen. Derzeit ist bei den täglich frisch veröffentlichten Builds GNOME 3.25.91 die Version der meisten GNOME-Pakete. Dies wird sich erst mit der Veröffentlichung von GNOME 3.26 ändern.
Gut integriert
Bei Canonical sind die Arbeiten zu 17.10 in vollem Gange und Vorfreude als auch Nervosität sind den Entwicklern deutlich anzumerken. Hieß es im Juli noch, Wayland sei »gefühlt noch nicht fertig«, kam dann zwei Wochen später die Bestätigung, Wayland werde bei 17.10 doch Standard. GNOME scheint mittlerweile gut in Ubuntu integriert, sodass Unity-Anhänger keine Probleme mit dem Umstieg haben sollten. Anwender, die GNOME dennoch nicht mögen, finden in Ubuntu MATE eine Alternative, die gerade eine erste Beta zu 17.10 veröffentlicht hat.
Release der kleinen Neuerungen
GNOME 3.26 ist kein Release mit umwerfenden Neuerungen, es wartet eher mit eher kleinen Verbesserungen über den gesamten Funktionsbereich hinweg auf und konsolidiert das Erreichte. Neben einem teils durchscheinenden Top-Panel wurden die Animationen bei Fensteraktionen überarbeitet. Die Desktop-Suche wurde aufgeräumt und bietet nun ein übersichtlicheres Bild und bessere Bedienbarkeit. Für Entwickler bietet GNOME 3.26 eine stark überarbeitete Version von Builder. Auch Flatpak erfuhr weitere Entwicklung. So wurde hier die Integration in GNOME Software weiter ausgebaut.
Status Icons ersatzlos entfernt
Nicht zuletzt wird mit GNOME 3.26 aber auch Funktionalität entfernt. Die Status-Icons werden aus dem Bereich des System-Tray verschwinden. Damit wurden bisher meist Anwendungen von dritter Seite angezeigt, die im Hintergrund laufen. Dazu zählen etwa Nextcloud, Slack, Discord, Steam, Skype, Mumble oder Dropbox. Die Mini-Leiste konnte durch einen kleinen Pfeil am linken unteren Bildschirmrand eingeblendet werden. Anwender, die die Leiste vermissen, können sich derzeit mit der Erweiterung TopIcons Plus ersetzen.
