Niri 26.04: Scrollender Tiling-Wayland-Compositor

 (github.com/niri-wm)
2 Punkte von GN⁺ 3 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die scrollende Tiling-Wayland-Compositor wurde durch Verbesserungen bei Hintergrundunschärfe, Screencasting, Rendering und der gesamten Eingabeverarbeitung deutlich ausgereifter
  • Hintergrundunschärfe ist jetzt im Mainline-Zweig enthalten, sodass Fenster und Layer-Shell-Elemente mit Unterstützung für ext-background-effect Unschärfe auch ohne separate niri-Konfiguration anfordern können und sich Unschärfe zusätzlich per Regel auf niri-Seite erzwingen lässt
  • Beim Screencasting wurden sowohl im PipeWire- als auch im wlr-screencopy-Pfad die Cursor-Behandlung, der Start dynamischer Casts, IPC-Abfragen und erzwungenes Beenden sowie Probleme mit mehrfachen Kopien und der Freigabe von Ressourcen überarbeitet
  • Die Rendering-Struktur wurde von einem iteratorbasierten auf ein pushbasiertes Modell umgestellt, wodurch der Aufbau der Render-Listen auf den Hauptmaschinen 2- bis 3-mal und auf einem alten Eee PC 8-mal schneller wurde, bei zugleich geringerem Speicherverbrauch
  • Auch ältere Hardware und Eingabeumgebungen wurden verbessert, etwa Screenshots und Screencasts auf alten Intel-Systemen, Konflikte zwischen IME und GTK-4-Popups, hochfrequente Mäuse und Tablet-Mapping sowie DMA-BUF-Beschleunigung in verschachteltem niri, wodurch sich der praktische Einsatzbereich erweitert

Wichtige Änderungen

  • Die GitHub-Organisation wurde vom persönlichen Account zu niri-wm verschoben; zugehörige Projekte wurden dabei ebenfalls neu organisiert
    • awesome-niri: Liste zugehöriger Projekte
    • artwork: Sammlung von Badges und Hintergrundbildern
  • Enthalten sind auch Änderungen für Paketierer
    • Die minimal unterstützte Rust-Version wurde auf 1.85 angehoben
    • niri.service hardcodiert den niri-Binärpfad nicht länger mit /usr/bin/
    • Die Struktur der dinit-Service-Datei wurde geändert: 3bfa4a7

Hintergrundunschärfe

  • Hintergrundunschärfe wurde in den Mainline-Zweig aufgenommen, und Fenster sowie Layer-Shell-Komponenten können über das Protokoll ext-background-effect Unschärfe anfordern
  • Auch wenn eine App ext-background-effect noch nicht unterstützt, kann Unschärfe auf niri-Seite über window-rule und layer-rule aktiviert werden
    • Details und Einschränkungen sind in der Dokumentation zu Window Effects zusammengefasst
    • In niri konfigurierte Unschärfe benötigt einen korrekten geometry-corner-radius
    • Bei komplexen Surface-Formen funktioniert dies nicht
  • Es gibt sowohl xray blur als auch normale Unschärfe; Standard ist xray blur
    • xray blur berechnet die Unschärfe des Hintergrundbilds nur einmal und verwendet sie wie ein statisches Bild wieder, was deutlich effizienter ist
    • Neu berechnet wird nur, wenn sich das Hintergrundbild ändert
    • Bei animierten Hintergrundbildern fällt der Effizienzvorteil geringer aus
    • Mit dem neuen layer-Matcher lässt sich normale Unschärfe stattdessen nur auf Layer wie top oder overlay anwenden
  • Die Umsetzung der Unschärfe war so anspruchsvoll, dass dafür Änderungen an der Rendering-Struktur nötig waren
    • Normale Unschärfe liest bereits gerenderte Pixel mitten im Frame erneut ein, macht sie unscharf und setzt das Rendering dann fort
    • Für xray blur mussten Fensterpositionen durch den gesamten Rendering-Code weitergereicht werden, damit der Hintergrund korrekt ausgeschnitten wird
    • In Overview musste Unterstützung für xray blur hinzugefügt werden, ohne die Eigenschaft zu verlieren, Overview nicht erneut zu rendern
    • Es musste außerdem mit für Screencasts ausgeblendeten Fenstern zusammenarbeiten
  • xray kann auch ohne Unschärfe allein verwendet werden; ebenso lassen sich Noise zur Minderung von Farbbanding und Sättigungseffekte separat nutzen
  • Mit dem neuen popups-Block können per window rule oder layer rule auch auf Popup-Menüs Transparenz und Hintergrundeffekte angewendet werden
    • Bei Formen, die keine abgerundeten Rechtecke sind, etwa GTK-4-Popups mit has-arrow=true, kann das Ergebnis unnatürlich wirken
    • Web-Apps oder Electron verwenden keine Wayland-Popups, daher kann niri sie nicht verarbeiten
    • Clients, die ext-background-effect direkt implementieren, können auch komplexere Unschärfeformen handhaben

Optionale include

  • Für config include wurde optionales include hinzugefügt
    • Mit include optional=true "optional-config.kdl" schlägt das Laden der Konfiguration nicht fehl, auch wenn die Datei fehlt
    • Fehlt die Datei, wird bei jedem Reload der Konfiguration zwar eine Warnung protokolliert, die Konfiguration wird aber weiter geladen
    • Wenn die Datei später auftaucht, wird die beobachtete Änderung erkannt und automatisch neu geladen
    • Existiert die Datei, enthält aber Syntaxfehler, gilt das weiterhin als fehlgeschlagenes Parsen
  • In include-Pfaden wird ~ zum Home-Verzeichnis expandiert
    • ~/file.kdl wird zu /home/user/file.kdl expandiert

Pointer-Warping und Scrollen

  • Während einer Geste zum Scrollen der Ansicht wird der Pointer nun von einem Bildschirmrand auf die gegenüberliegende Seite gewarpt
    • Das Verhalten ähnelt Blender
    • Dadurch lässt sich auch bei einem Start nahe am Monitorrand natürlich weiter durch mehrere Fenster scrollen

Verbesserungen beim Screencasting

  • Das Screencasting von niri wurde sowohl über xdg-desktop-portal-gnome via PipeWire als auch über wlr-screencopy verbessert.

  • Cursor-Behandlung beim Fensterscreencast

    • PipeWire unterstützt nun Cursor-Metadaten, statt den Cursor direkt in die Videoframes zu zeichnen.
      • Der Cursor ist nicht mehr im Videoframe enthalten; stattdessen werden Cursor-Icon und Koordinaten in einem separaten Buffer gesendet.
      • Verbraucher wie OBS oder Browser zeichnen den Cursor dadurch selbst.
    • Das funktioniert sowohl bei Monitor- als auch bei Fensteraufnahmen.
    • Bei Fensteraufnahmen wird der Cursor nur dann angezeigt, wenn er tatsächlich auf dieses Fenster oder dessen Pop-ups zeigt.
    • Auch Drag-and-Drop-Icons werden mitgezeichnet.
    • Bei der Implementierung wurde zudem ein Speicherbeschädigungsproblem in PipeWire aufgedeckt und behoben.
    • Außerdem wurde eine Diskrepanz zwischen der beabsichtigten PipeWire-Funktionsweise und Implementierungen von Verbrauchern wie libwebrtc festgestellt.
    • In den getesteten Umgebungen funktioniert es korrekt.
    • Mit screenshot-window show-pointer=true lässt sich der Pointer auch in Fensterscreenshots einblenden.

  • Geändertes Startverhalten für Dynamic cast target

    • Dynamic cast target ist eine Funktion, mit der sich das Screencast-Ziel per Tastenkürzel sofort umschalten lässt.
    • Bisher startete sie zunächst mit einem 1×1 großen schwarzen Pixel-Videostream.
    • Jetzt wird der Start des Videostreams verzögert, bis das erste echte Ziel ausgewählt ist.
    • Dadurch lässt sich das kurzzeitige 1×1-Video in Microsoft Teams vermeiden.

  • Cast IPC

    • Laufende Screencasts lassen sich nun per IPC abfragen.
    • Mit niri msg casts können aktive Casts angezeigt werden.
    • Im Event-Stream kann man Cast-Events abonnieren.
    • Das Objekt Cast liefert Typ, aktuelles Ziel und Aktivstatus.
    • PipeWire-Screencasts liefern eine Node-ID, wlr-screencopy dagegen die Client-Prozess-ID.
    • DankMaterialShell zeigt bereits mithilfe dieser IPC einen Screencast-Indikator an.
    • Mit niri msg action stop-cast --session-id <ID> lässt sich ein PipeWire-Screencast zwangsweise beenden.

  • Einschränkungen und Fixes rund um wlr-screencopy

    • wlr-screencopy bietet keine robuste Möglichkeit, zwischen Screencast und Screenshot zu unterscheiden, daher sind einige Heuristiken nötig.
    • xdg-desktop-portal-wlr hält dauerhaft ein einzelnes wlr-screencopy-manager-Objekt, wodurch sich der Endzeitpunkt nicht direkt erkennen lässt.
    • Diese Probleme werden durch das neue Protokoll ext-image-copy-capture gelöst, das in niri aber noch nicht enthalten ist.

  • Weitere Screencast-Fixes

    • Ein Problem wurde behoben, bei dem bei der Damage-Kopie der Cursor bei wlr-screencopy-Clients immer mit enthalten war, auch wenn der Client ihn nicht wollte.
    • Das Verhalten bei gleichzeitig angeforderten Kopien mehrerer Frames mit Damage wurde korrigiert.
    • Ein Problem wurde behoben, bei dem wlr-screencopy-Daten in niri in einigen Fällen, etwa nach dem Beenden des Clients, nicht freigegeben wurden.
    • Die Standardanzahl der PipeWire-Screencast-Buffer wurde von 16 auf 8 reduziert.
    • Die Reihenfolge der Struct-Felder wurde angepasst, um ein Use-after-free-Problem in pipewire-rs zu vermeiden.
    • Ein Rendering-Problem wurde behoben, bei dem beim Wechsel eines Dynamic-cast-Ziels auf ein Fenster die Z-Order für einen Frame falsch war.

Animationen und Fensterverhalten

  • Die Synchronisierung von Animationen ist präziser geworden.
    • niri erlaubt zwar die getrennte Konfiguration einzelner Animationen, führt sie aber synchronisiert aus, wenn sie exakt zusammenpassen müssen.
    • Animationen zur Fenstergrößenänderung werden mit den dadurch ausgelösten horizontalen View-Verschiebungsanimationen synchronisiert.
    • Ein Problem wurde behoben, bei dem beim Verlassen von Fullscreen oder Maximized die Synchronisierung der View-Verschiebung fehlte, sodass das Fenster sofort zurücksprang, während der Bildschirm noch langsam scrollte.
  • Ein Problem wurde behoben, bei dem die horizontale Verschiebungsanimation anderer Tile-Fenster bei bestimmten Drag-Pfaden übersprungen wurde.
    • Es trat auf, wenn ein maximiertes Fenster per Drag aus dem maximierten Zustand gelöst und, falls es ursprünglich floating war, wieder in den Floating-Zustand versetzt wurde,
    • und sich dabei die Logik für das Scrollen zu linken oder rechten Workspaces bei einem Drag nahe am Monitorrand überlappte.
    • Fix-Commit: df3f3979e936ed6800b4fbd55843bb0fe2554f15
  • Auch ein Problem wurde behoben, bei dem die ganz linke Spalte eines Workspace nach dem Herausziehen und erneuten Ablegen nicht an ihre ursprüngliche Position, sondern nach rechts einsortiert wurde.
  • Die Anzeigedauer von Benachrichtigungen über Konfigurationsfehler wird nun nicht mehr von den Animationseinstellungen für Verlangsamung/Beschleunigung beeinflusst.

IME und Pop-ups

  • Ein altes Problem, bei dem GTK-4-Pop-up-Eingabefelder und IME nicht zusammen funktionierten, wurde mit einem Workaround gelöst.
    • Bei aktivem IME wie Fcitx5 ließen sich Text-Pop-ups nicht öffnen.
    • Die Pop-ups griffen Pointer und Tastatur, und auch das IME verwendete einen Keyboard-Grab, was zu einem Konflikt führte.
    • niri verwarf daraufhin den Pop-up-Grab, wodurch sich das Pop-up oft sofort wieder schloss.
    • Einige Prüfungen wurden gelockert, damit es funktioniert, ohne die Smithay-Struktur vollständig umzubauen.
    • IME-Nutzer können nun beispielsweise in Nautilus Dateinamen umbenennen.

Drag-and-Drop und Eingabegeräte

  • Während eines Drag-and-Drop-Vorgangs kann die Aktion nun mit Escape abgebrochen werden.
  • Auch bei Eingabegeräten allgemein gab es mehrere Fixes.
    • Ein Problem wurde behoben, bei dem das System mit der Zeit langsamer wurde, wenn Mäuse mit hoher Polling-Rate zusammen mit hide-after-inactive-ms oder einem Idle-Monitoring-Daemon verwendet wurden.
    • Mit libwayland-server v1.23 oder neuer wird die Größe des Wayland-Buffers erhöht, damit Fenster bei Mausbewegungen mit hoher Polling-Rate über nicht reagierenden Fenstern nicht so schnell abstürzen.
    • Es wurde die Tablet-Option map-to-focused-output hinzugefügt, mit der statt eines fest angegebenen einzelnen Outputs der aktuell fokussierte Output verwendet werden kann.
    • Ein Problem wurde behoben, bei dem der Cursor am obersten Pixel eines Workspace nicht immer korrekt auf ein maximiertes Fenster zeigte.
    • Ein Problem wurde behoben, bei dem Alt-Tab schon auf Mauseingaben reagierte, bevor es auf dem Bildschirm sichtbar war.
    • on-button-down-Scrolling von Trackballs funktioniert nun auch in der Overview.
    • Der Num-Lock-Status bleibt nun auch nach dem Laden einer benutzerdefinierten .xkb-Keymap erhalten.
    • Ein Problem wurde behoben, bei dem Eingabegeräte gar nicht verwendet werden konnten, wenn der Start über tmux von einer anderen TTY aus erfolgte.
    • Das Laden von libinput-Plugins wurde aktiviert.

GPU-Profiling und Rendering-Optimierung

  • Für Tracy, das in Smithay und niri verwendet wird, wurde integriertes GPU-Profiling hinzugefügt
    • In Smithay wurde Unterstützung dafür aufgenommen, GPU-Timestamp-Queries abzusetzen, fertige Werte zu sammeln und an Tracy zu senden: Arbeits-PR
    • Sowohl interne GPU-Arbeit von Smithay als auch GPU-Arbeit des Compositors selbst kann nun mit Bereichen markiert werden
    • Es lässt sich nachvollziehen, wie sich innerhalb eines einzelnen Frames das Rendering von DRM-Buffern und das Rendering von PipeWire-Screencast-Buffern überlappen
    • Auf Multi-GPU-Systemen lassen sich außerdem Tracks pro GPU prüfen
    • Es konnte bestätigt werden, dass die Blur-Performance nicht langsamer ist als erwartet, und auch die Diagnose von dropped frames durch GPU-Rendering-Engpässe wurde einfacher
  • Die Methode zum Aufbau der Render-Liste wurde von einer iteratorbasierten auf eine push-basierte Struktur umgestellt
    • Bisher wurden Render-Elemente in der Form -> impl Iterator<Item = ...> zusammengesetzt
    • Dabei gab es verschiedene Komplexitäten wie bedingte Verzweigungen, lifetimes, das Leihen von &self, Konflikte mit &mut Renderer, Zwischenallokationen für Vec und Probleme an crate-Grenzen
    • In der neuen Struktur nimmt die Render-Funktion push: &mut dyn FnMut(Element) entgegen und fügt Elemente per Push ein
    • Zwischenfunktionen können die bisherige Logik beibehalten, indem sie Closures verwenden, die das übergeordnete push kapseln
    • Temporäre Vecs entfallen, und auch die Borrowing-Probleme verschwinden
    • In niri wurde der Vorteil eines vorzeitigen Iterator-Abbruchs in der Praxis nicht benötigt
  • Durch dieses Refactoring wurde der Aufbau der Render-Liste deutlich schneller
    • Auf der Hauptmaschine 2- bis 3-mal schneller
    • Auf einem alten Eee PC 8-mal schneller
    • Der Aufbau der Render-Liste ist zwar nicht die eigentliche GPU-Rendering-Zeit, wird aber häufig ausgeführt, auch wenn der Bildschirm nicht neu gezeichnet wird, daher ist der Effekt der Verbesserung groß
    • Auch der Speicherverbrauch wurde reduziert, und im neuen Pfad bleiben Allokationen größtenteils nur noch beim Erweitern des Ausgabevektors übrig
    • Ausführliche Motivation und Diff finden sich im PR

Unterstützung für ältere Hardware

  • Die Ursache dafür, dass Screenshots auf alten Intel-Laptops fehlschlugen, stellte sich als falscher OpenGL-Enum-Wert in Smithay heraus und wurde behoben: PR zur Ursachenanalyse
  • Auch die niri-Shader wurden leicht optimiert, sodass selbst auf der eingeschränkten GPU eines sehr alten ASUS Eee PC
    • Fenstergrößenänderungs-Animationen
    • abgerundete Ecken des Compositors
    • wieder funktionieren

Weitere Verbesserungen

  • Ein Problem mit VRAM-Lecks, das auf manchen Systemen nach dem Beenden bestimmter Apps auftrat, wurde behoben
  • Das Protokoll ext-foreign-toplevel-list wurde hinzugefügt, wodurch sich in Quickshell und ähnlichen Projekten Wayland-Fensterobjekte leichter mit niri-IPC-Fenster-IDs verknüpfen lassen
  • Wenn in der Konfiguration ein Fehler durch doppelte Bindings auftritt, wird nun auch die Position der ersten Definition desselben Bindings angezeigt
  • Beim Ziehen von Fenstern mit Mod+LMB wird nun ein grabbing cursor angezeigt
  • Für niri msg action load-config-file wurde das Argument --path hinzugefügt, sodass sich zur Laufzeit auf eine andere Konfigurationsdatei umschalten lässt
  • Nested niri erhält DMA-BUF-Unterstützung, sodass Hardware-Beschleunigung auch nach der Abschaffung von Mesas wl_drm wieder funktioniert
  • Das Padding, das niri bei layer-shell-Popups nahe am Bildschirmrand eingefügt hatte, wurde entfernt
  • Änderungen an der Standardkonfiguration sind ebenfalls enthalten
    • Mod+M: maximize-window-to-edges
    • Mod+Shift+R: switch-preset-column-width-back
  • Das Debug-Flag force-disable-connectors-on-resume wurde hinzugefügt, um beim Wechsel auf TTY oder beim Aufwachen aus dem Standby den Bildschirm zwangsweise auf blank zu setzen
  • Es wurde behoben, dass Fensterecken im windowed fullscreen nicht korrekt als rechte Winkel dargestellt wurden
  • Ein Problem wurde behoben, durch das der Bildschirm weiter neu gezeichnet wurde, solange die Overview geöffnet war
  • Das Rendering des gradient border mit relative-to=workspace-view während interaktiven Dragging wurde leicht korrigiert
  • Das Rendering des Diaeresis-Shortcuts im Dialog „Important Hotkeys“ wurde verfeinert
  • Die Beschreibung von expel-window-from-column in niri msg action wurde passend zum tatsächlichen Verhalten auf das Ausstoßen des unteren Fensters korrigiert
  • Mehrere Panics wurden behoben, die auftreten konnten, wenn Clients kürzlich entfernte Outputs verwenden wollten
  • Es wurde behoben, dass clip-to-geometry fehlerhaft renderte, wenn es zusammen mit Clients verwendet wurde, die y_invert-Buffer anhängen
  • Der OpenBSD-Build wurde repariert
  • Nested niri setzt nun die eigene Fenster-app-id
  • Wenn eine neue GPU eingesteckt wird, wird die Debug-Einstellung ignore-drm-device erneut ausgewertet, sodass auch symbolische Links unter /dev/dri/by-path/ genutzt werden können

Smithay-Updates übernommen

  • Mit den Smithay-Updates kommen auch mehrere grundlegende Verbesserungen
    • Die automatische GPU-Auswahl wurde auf manchen Geräten wie ARM-Macs verbessert
    • Asahi und Pinephone funktionieren nun direkt ohne manuelle Einstellung von render-drm-device
    • Das Verhalten einiger layer-shell-Clients wie wl_shimeji wurde verbessert
    • Die Unterstützung für Docks, bei denen die Monitor-EDID spät geladen wird, wurde verbessert
    • Screenshots und Screencasts funktionieren auf älteren Intel-Systemen
    • Ein Problem wurde behoben, bei dem alte Outputs zurückblieben, wenn während des Standby ein USB-C-Dock getrennt wurde
    • Ein zxdg_exporter_v2-Panic in einigen Clients wurde behoben
    • Ein Speicherleck in Clients, die Clipboard-Protokolle nicht explizit zerstören, wurde behoben
    • Panics in Zusammenhang mit text-input content hint und purpose, die ab den GTK-4.23-Entwickler-Releases auftraten, wurden behoben
    • Drag-and-drop, IME-Texteingabe, Multi-GPU und die Gesamtperformance wurden ebenfalls verbessert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 일 전
Hacker-News-Kommentare

  • Niri ist so gut, dass es sich, seit ich vor etwa 5 Monaten gewechselt bin, wie eine der besten Entscheidungen der letzten Jahre anfühlt, Windows hinter mir gelassen zu haben
    Ich bin dem Autor wirklich sehr dankbar
    Meine dotfiles enthielten ursprünglich Installationsskripte für CLI-Tool-Konfigurationen, Theme-Umschaltung usw., und inzwischen unterstützen sie Niri auf Arch-basierten Systemen ebenfalls vollständig
    Wenn man schnell eine neue Desktop-Umgebung ausprobieren will, ist https://github.com/nickjj/dotfiles ein ziemlich guter Startpunkt
    Ich nutze es sowohl auf meinem Haupt-Desktop als auch auf meinem Reise-Laptop

    • Bei mir genauso, und die Kombination aus ultrawidem Curved-Monitor und Niri passt besonders gut
    • Man sollte sich auch Nirimod unbedingt ansehen
      Ist inoffiziell, aber wirklich großartig
    • Omarchy hat eine Art umschaltbaren scrollbaren Modus pro Workspace eingebaut
      Mit Win/Cmd + L wechselt man zwischen Tiling und Scrolling, und ich nutze das inzwischen sehr oft

  • Dank Niri bin ich zum ersten Mal mit scrollbasierter Fensterverwaltung in Kontakt gekommen, und es hat sofort Klick gemacht
    Vor Kurzem hat OmniWM für den Mac einen vollständigen Niri-Emulationsmodus pro Workspace bekommen, und zum Glück ist er auch mit Sequoia kompatibel, sodass es sofort mein primärer Fenstermanager geworden ist
    [1] https://github.com/BarutSRB/OmniWM

    • Paneru ist ein neues Tool, das ausdrücklich dafür entwickelt wurde, Niri auf macOS nachzuahmen
    • Bei mir ähnlich
      Als ich Niris Ansatz zum ersten Mal gesehen habe, hat er mir sofort gefallen, und ich habe auf dem Mac weiter nach etwas Ähnlichem gesucht
      Es ist die beste Implementierung, die ich bisher ausprobiert habe, und klar, es gibt ein paar kleine quirks, aber zumindest für mich taugt es absolut als Daily Driver
      Besonders die tabbed columns sind wirklich gut
      Applaus an Maintainer und Mitwirkende

  • Wenn du einen Mac nutzt, kann ich OmniWM empfehlen
    Es bietet nicht nur Niri-artige Layouts, sondern auch Layouts, die näher an Hyprland sind, und dadurch ist das Arbeiten auf macOS deutlich angenehmer geworden
    https://github.com/BarutSRB/OmniWM
    Ich hatte schon einmal darüber gepostet, als ich gerade angefangen hatte, es zu nutzen, aber nachdem ich es weiter verwendet habe, finde ich es wirklich gut und kann es klar empfehlen

    • Tut mir leid, aber das Demovideo ist eines der schlechtesten Demovideos, die ich je in meinem Leben gesehen habe
      Nach diesem Video wird niemand Lust bekommen, die Software auszuprobieren, und selbst als bestehender Nutzer hätte man fast das Bedürfnis, sie zu deinstallieren

  • Ich nutze die PaperWM extension für GNOME, und Niri scheint sich vermutlich davon inspirieren zu lassen
    Es ist definitiv eine interessante Arbeitsweise, aber sobald man mehr als 3 Fenster in einem Workspace hat, fühlt es sich etwas umständlich an, daher liebe ich es nicht uneingeschränkt
    Ich probiere es aber weiterhin ernsthaft aus, und da es eine GNOME extension ist, ist es schön, den Rest der GNOME-DE ohne große zusätzliche Einrichtung weiter nutzen zu können

    • Ich wollte schon länger zu Niri wechseln, aber das Einrichten der zusätzlichen Konfiguration hat jedes Mal mehrere Tage gekostet
      Man musste sich eben auch um Dinge wie top bar, idle timeout und Benachrichtigungen kümmern
      Vor Kurzem habe ich aber erfahren, dass es Desktop-Shells für Wayland gibt, die vieles von dem liefern, was man aus Umgebungen wie GNOME erwartet, und das ohne großen Aufwand
      Sie enthalten Konfigurationsdialoge, App-Tray, Ressourcenüberwachung und top bar
      Ich nutze gerade dank material shell, und es ist wirklich cool, dass man Desktop-Shell und Compositor frei kombinieren kann
    • Bei mir genauso, ich mag daran, dass PaperWM eine nicht invasive GNOME extension ist
      Mein Workflow ist insgesamt besser geworden, und ich konnte dadurch auch noch zwei oder drei andere Extensions wie desktop grid löschen

  • Ich habe mich komplett daran gewöhnt, schnell zwischen mehreren dedizierten Fullscreen-Workspaces zu wechseln und Fenster nur per Tastatur zu verwalten, also an diesen Tiling-WM-Workflow
    Normalerweise habe ich pro Workspace eine App oder ein Terminal mit tmux offen und stelle nur gelegentlich zwei Apps nebeneinander
    Mich interessiert wirklich, wie sich bei Leuten mit einem ähnlichen Ablauf das mentale Modell verändert, wenn sie zu Niri wechseln

    • Ich habe unter KDE, GNOME und Niri immer Workspaces nach Aktivitäten/Projekten verwendet
      Ein Workspace mit Steam und einem Spiele-Wiki, ein Workspace mit Emacs und einem Dokumenten-Browser, ein Workspace mit Godot und Apps für die Spieleentwicklung usw.
      Das Gute an Niri ist, dass man fast nie das Gefühl hat, zu viele Fenster zu haben und etwas schließen zu müssen
      Es ist ziemlich einfach, Dinge getrennt und geordnet zu halten
      Ich verstehe nicht so ganz, warum man Workspaces pro App verwenden sollte
      Ich mag es auch nicht, wenn in einem Firefox Arbeit und Hobby-Tabs durcheinander sind
    • Ich bin schon ziemlich lange Tiling-Nutzer und hatte eine ähnliche Konfiguration
      awesome, qtile, kurz xmonad, dann i3, beim Wechsel zu Wayland sway und auch ein wenig hyprland
      Das Problem war immer, dass horizontale Anordnungen mit mehr als 3 Fenstern nicht gut funktionieren und vertikale Splits zu klein werden
      Gleichzeitig kam es oft vor, dass ich neben dem, was ich gerade las, ein neues Fenster öffnen oder neben dem Terminal einen ipython-Plot sehen wollte
      Jedes Mal musste ich es dann per stacked layout bündeln oder in einen neuen Workspace verschieben, was ziemlich viel Reibung erzeugte und meinen Arbeitsfluss immer wieder unterbrach
      In Niri öffne ich einfach ein neues Fenster, es erscheint an der richtigen Stelle, und die anderen Fenster bleiben links und rechts erhalten, sodass ich einfach hin scrollen kann
      Mein Workflow ist dadurch jetzt etwas unordentlicher als früher, aber gerade das gefällt mir
      Klassische Tiling-WMs verlangen Ordnung und machen sie leicht, aber in Niri muss man nicht unbedingt aufräumen
      Wenn ich ein Fenster einmal nicht sofort finde, nutze ich die Übersicht, und ich habe mit rofi auch Fenstersuche ergänzt
      Anfangs habe ich aus sway-Gewohnheit weiter benannte Workspaces benutzt, inzwischen aber nicht mehr
    • Ich bin von KDE aus fast mit genau demselben Ablauf gekommen
      Workspace 1 war ein Fullscreen-Terminal mit zellij, 2 der Browser, 3 etwa zwei Chat-Apps, und dazwischen bin ich mit Shortcuts gewechselt
      Anfangs habe ich Niri genutzt, weil es leichter und anders als Plasma war, inzwischen hat sich aber auch mein Workflow etwas verändert
      Die meisten Fenster nutze ich immer noch in Bildschirmgröße, und ich organisiere weiterhin ähnlich: 1 für Entwicklung, 2 für Browser und gelegentlich einen Mail-Reader, 3 für Chat-Apps
      Allerdings öffne ich jetzt viel häufiger neue Terminal-Fenster, wenn ich kurze Befehle eintippe oder lang laufende Aufgaben offen lassen will
      Unter KDE lagen solche Fenster übereinander im Hintergrund, jetzt stehen sie innerhalb von 1 nebeneinander
      Rückblickend wirkt der frühere Wechsel per Alt-Tab inzwischen ziemlich umständlich, und mit Super-hjkl zwischen Fenstern zu gehen fühlt sich viel leichter an
      Natürlich ist das subjektiv, aber dieses Gefühl, dass Fenster nebeneinander statt übereinander liegen, macht den Workflow leichter
    • Das klingt eigentlich weniger nach Tiling als nach einer Kombination aus Fullscreen und Workspaces
      Mit manuellen Tiling-WMs wie i3 oder sway und einem großen Monitor kann man den Bildschirm in mehrere Arbeitsbereiche aufteilen, in denen jeweils mehrere Apps mit unterschiedlichen Rollen liegen, und so die Zahl der Workspaces reduzieren
      Scrolling ist ein ähnlicher, aber anderer Workflow und passt besonders gut, wenn auf kleineren Bildschirmen Flexibilität wichtig ist
    • Ein Workspace pro App ergibt bei Tiling-WMs meiner Meinung nach wenig Sinn
      Dieser Workflow passt eher zu Floating-WMs
      Der eigentliche Vorteil von Tiling-WMs liegt im tatsächlichen Kacheln von Fenstern, und für mich ist die holy trinity aus Browser, Editor und Terminal entscheidend
      Außerdem sollte man sich räumlich mit super+hjkl oder den Pfeiltasten bewegen können
      Deshalb wirken Workspaces pro Projekt viel natürlicher und eher wie ein echter Tiling-WM-Workflow
      Niri macht das deutlich besser, weil neue Fenster rechts geöffnet werden und das aktuelle Layout nicht zerstören
      Wenn man zum Beispiel ein PDF öffnet, kann man leicht zum neuen Fenster wechseln, ohne die bestehende Anordnung zu verlieren

  • Hier sind verwandte Links
    The dank case for scrolling window managers - https://news.ycombinator.com/item?id=46820468 - Jan 2026 (61 comments)
    Niri 25.11 released with alt-tab and other improvements - https://news.ycombinator.com/item?id=46097051 - Nov 2025 (1 comment)
    Niri – A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=45461500 - Oct 2025 (229 comments)
    The Future Is Niri - https://news.ycombinator.com/item?id=43342178 - March 2025 (216 comments)
    Niri: A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=37367687 - Sept 2023 (37 comments)

  • Wenn du die NNN (Niri-Nix-Noctalia) dots ausprobieren willst, kannst du gern mein flake nehmen
    https://github.com/MostlyKIGuess/nix-flake-public

    • Ich habe zwar mehrere Jahre Window Manager genutzt, bin aber wegen der Hürde, auch die Konfiguration außerhalb des WM selbst anpassen zu müssen, am Ende wieder zu einer vollständigen Desktop-Umgebung zurückgekehrt
      Selbst Dinge wie Dark Mode waren mit viel Handarbeit verbunden, und Noctalia sieht genau nach der Richtung aus, die ich mir gewünscht hatte
      Danke für den Hinweis

  • Ich nutze den wl-only-Branch von mangowm (auf Basis von wlroots 0.20)
    Er braucht deutlich weniger Ressourcen, hat mehr Layouts und weniger Probleme
    Niri sieht bei den visuellen Effekten zwar besser aus, aber es ist auf jeden Fall einen Versuch wert
    Für HDR muss man noch warten
    https://github.com/mangowm/mango

    • Mich würde interessieren, welche Probleme genau du meinst
      Bei mir war Niri wirklich rock solid

  • Es wirkt, als hätte ein russisches Genie etwas gebaut, das besser ist als 100 Millionen Dollar an Claude-Tokens
    Also definitiv kein kompletter kollektiver Wahnsinn, deshalb soll offenbar lieber jeder SPY kaufen

    • Scheint wirklich ein Genie zu sein
      Wenn man die Release Notes liest, sind sie fast schon für sich genommen schön

  • Ende letzten Jahres bin ich nach über 10 Jahren mit i3 zu Niri gewechselt
    Das horizontale Scrollen, das nicht an die Monitorgröße gebunden ist, und die Zahl der Workspaces, die nicht durch die Anzahl der konfigurierten Hotkeys begrenzt wird, fühlen sich wirklich befreiend an
    Auch grafisch ist das Ganze sehr ausgereift
    Mein einziger verbleibender Kritikpunkt ist, dass die X-Kompatibilitätsschicht xwayland-satellite Drag-and-Drop zwischen X-Apps und Wayland-Apps noch nicht unterstützt
    [1]: https://davidyat.es/2026/01/28/niri/
    [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

    • Bei mir ähnlich
      Früher hatte ich die Gewohnheit, immer dieselben Dinge auf denselben Workspaces zu haben, sodass ich sie leicht wiederfand, aber jetzt verteilt sich das Layout viel stärker
      Und ich vermisse scratch ziemlich stark
      Mit etwas mehr Fleiß bei der Konfiguration ließe sich das vermutlich beheben, aber bisher habe ich noch keine Zeit dafür aufgebracht