Niri, un compositeur Wayland à tuiles défilantes

• Niri est un compositeur Wayland à tuilage défilant, qui dispose les fenêtres horizontalement de manière infinie
• Une structure où la taille des fenêtres existantes ne change pas à l’ouverture d’une nouvelle fenêtre, chaque moniteur disposant de sa propre bande de fenêtres indépendante
• Propose des fonctionnalités modernes comme les espaces de travail dynamiques, les groupes d’onglets et les gestes souris/pavé tactile
• Prend en charge le multi-écran, l’intégration Xwayland, le fractional scaling et divers environnements adaptés à un usage réel
• Grâce à sa grande stabilité basée sur Rust et à ses optimisations de performance, il est recommandé par de nombreux utilisateurs pour un usage quotidien

---

Vue d’ensemble

• Niri est un compositeur Wayland open source prenant en charge une gestion des fenêtres en tuilage basée sur le défilement, offrant une interface d’agencement des fenêtres originale et suffisamment stable pour un usage quotidien
• Contrairement aux tiling window managers classiques, il place les fenêtres en colonnes qui s’étendent indéfiniment vers la droite, sans redimensionner automatiquement les fenêtres existantes lorsqu’une nouvelle fenêtre est ouverte
• Chaque moniteur possède sa propre bande de fenêtres indépendante, et les fenêtres ne basculent pas vers l’écran voisin

Fonctionnalités principales

• Espaces de travail dynamiques : comme dans GNOME, des espaces de travail indépendants sont créés et gérés dynamiquement dans le sens vertical pour chaque moniteur
• Lors de la connexion ou déconnexion d’un moniteur, la disposition des espaces de travail est préservée, et lors de la reconnexion, ils reviennent sur leur moniteur d’origine
• Vue d’ensemble des espaces de travail/fenêtres : un mode Overview qui permet de voir d’un coup d’œil l’organisation des fenêtres et des espaces de travail
• Interface intégrée pour les captures d’écran et l’enregistrement, avec prise en charge du screencasting/streaming via xdg-desktop-portal-gnome
  • Possibilité de masquer les fenêtres sensibles dans un screencast
  • Prise en charge du changement dynamique de la fenêtre cible
• Gestes pavé tactile/souris, regroupement des fenêtres en groupes d’onglets, nombreux réglages de disposition (marges, bordures, taille des fenêtres, etc.)
• Bordures en dégradé (Oklab, Oklch), animations (avec shaders personnalisés), rechargement à chaud du fichier de configuration
• Prise en charge des lecteurs d’écran pour renforcer l’accessibilité

Installation et conseils d’usage

• Suffisamment stable pour un usage réel, et déjà utilisé avec satisfaction au quotidien par de nombreux utilisateurs
• Comme il ne s’agit pas d’un environnement de bureau complet, il est recommandé de l’associer à Waybar (panneau) et Fuzzel (lanceur)
• Les projets associés, add-ons et la documentation sont disponibles dans awesome-niri

Environnement et compatibilité

• La conception multi-écran est au cœur du projet, avec une prise en charge complète des DPI mixtes et du fractional scaling
• Fonctionne également sans problème avec les GPU NVIDIA
• Prise en charge des floating windows (à partir de la version 25.01)
• Compatible avec divers périphériques d’entrée comme les tablettes, pavés tactiles et écrans tactiles (avec prise en charge des gestes du pavé tactile)
• Compatible avec les principaux protocoles Wayland (layer-shell, gamma-control, screencopy, etc.)
• Xwayland (via l’intégration xwayland-satellite, à partir de la version 25.08), ainsi qu’une optimisation pour les systèmes légers (des exécutions sur des machines modestes comme l’Eee PC 900 ont déjà été rapportées)

Développement et communauté

• Implémenté en Rust, avec une excellente stabilité, une maintenance efficace et de très bonnes performances
• Inspiré par PaperWM (extension GNOME Shell), avec un accent mis sur l’indépendance de chaque moniteur et l’optimisation des performances
• La communauté est active sur Matrix et Discord pour l’entraide et les échanges
• Divers contenus externes présentent le projet, notamment des interviews du développeur, des présentations techniques et des articles de LWN

Projets similaires

• Peut être comparé à divers projets qui mettent en œuvre un workflow de tuilage défilant, comme PaperWM pour GNOME Shell, karousel pour KDE, scroll·papersway basé sur sway/i3, hyprscrolling·hyprslidr pour Hyprland, ou encore PaperWM.spoon pour macOS

Contribution et informations open source

• La communauté peut contribuer dans de nombreux domaines, techniques ou non ; voir CONTRIBUTING.md pour plus de détails
• La licence est GPL-3.0
• Le code est principalement composé de Rust (98,9 %), avec la participation de nombreux contributeurs externes

Résumé

Niri est un compositeur pour Wayland qui combine une UX originale de gestion des fenêtres en tuilage défilant avec de nombreuses fonctionnalités modernes, ainsi qu’une grande fiabilité, de bonnes performances et une accessibilité renforcée grâce à sa base Rust. Il se distingue particulièrement par sa gestion du multi-écran et sa capacité à s’adapter à différents workflows, tandis que son écosystème open source et sa communauté continuent de se développer activement.

[ndrgrd]

Je l’ai déjà utilisé auparavant ; ce n’est pas mauvais, mais dès qu’on ouvre plusieurs fenêtres, l’intérêt du défilement disparaît.
Au départ, c’est déjà trop loin pour se déplacer, et comme on ne se souvient même plus d’où se trouvait la fenêtre, on finit simplement par la retrouver avec une recherche textuelle.

La méthode souvent utilisée des « numéros de groupe » est facile à mémoriser, car elle se prête bien à une classification selon un critère précis (les plus utilisés, ou par usage).

[GN⁺]

Avis Hacker News

• Grâce à Niri, même moi qui utilisais xmonad depuis 14 ans, j’ai complètement migré. Avec Niri, il n’y a pas de limite au nombre de fenêtres dans le bureau, et comme il n’est pas nécessaire de réorganiser sans cesse la structure de tuilage, ce que je répartissais autrefois sur plusieurs bureaux thématiques se gère maintenant facilement sur un seul bureau. Avant, je séparais un bureau « éditeur et terminal » d’un bureau « navigateur », alors que maintenant je peux simplement me déplacer horizontalement dans le même bureau pour accéder aux fenêtres de navigateur associées, ce qui est très pratique. La barrière d’entrée est très faible et ça fonctionne bien avec la configuration par défaut. Il y a eu quelques soucis de prise en charge Wayland, notamment avec certaines apps comme Zoom, mais cela se résout progressivement avec le temps. Mon matériel : un System76 Bonobo WS de 2017, 2x GTX 1080, plusieurs écrans (4k en échelle 2x + 2 écrans 1080p), sous PopOS. Je n’ai pas encore vu passer les changements plus tape-à-l’œil comme les animations fancy, et comme je fais partie des gens qui trouvent la barrière d’entrée faible tant qu’il n’est pas difficile de compiler les sources soi-même, mon avis est peut-être biaisé

  • Récemment, Niri a amélioré l’intégration de xwayland-satellite, ce qui permet de lancer facilement des programmes ne prenant pas en charge Wayland lien connexe

  • Ce qui rend i3/sway intéressants, c’est la possibilité d’assigner des bureaux par thème (navigateur, code, Slack, etc.) : il suffit d’un raccourci clavier pour aller directement au bon bureau, et l’efficacité au travail était bien supérieure à celle de MacOS, qui dépend énormément de CMD+Tab ou de Mission Control. Le défilement de Niri me donne plutôt l’impression d’errer à la recherche d’une fenêtre, donc ça m’étonne

  • J’ai aussi utilisé i3 pendant plus de 10 ans, mais avec Niri j’ai eu un moment de « ah oui ! » dès la première utilisation. Les builds récentes ont ajouté une fonction de zoom arrière façon « minimap », très utile quand on ne sait plus trop où l’on se trouve

  • La seule chose qui me manque vraiment dans Niri, c’est une scratch layer. Certaines apps n’ont pas besoin d’être tuilées et devraient pouvoir être invoquées instantanément depuis n’importe où ; par exemple, ce serait pratique pour un client Matrix afin de pouvoir répondre tout de suite. Même chose pour les lecteurs multimédia. Le Paperwm de GNOME a cette fonctionnalité

  • J’utilise i3 depuis plus de 7 ans, et je ne vois pas bien en quoi le défilement est intéressant. Les WM en tuilage produisent plein de jolies captures d’écran, mais je me demande à quel point cela aide réellement la productivité. Je me demande aussi comment fonctionne le déplacement horizontal : par exemple, si on passe d’un éditeur en plein écran à un navigateur seulement à moitié visible, est-ce que l’éditeur est tronqué ou compressé ? Et j’aimerais bien voir un WM en tuilage intégré plus profondément à dmenu, qui fasse aussi navigateur

• J’utilise Niri sur mon bureau principal depuis quelques mois et j’ai rédigé un retour d’expérience sur LWN. Les WM/compositeurs en tuilage classiques ne me convenaient pas vraiment, mais le modèle de tuilage de Niri, lui, me correspond parfaitement. Avant Niri, j’utilisais PaperWM et des extensions GNOME, mais si COSMIC ajoute seulement le tuilage défilant, je pense sans doute rester sur Niri

  • Il est possible que l’équipe COSMIC ajoute cette fonctionnalité après la sortie de la 1.0. En attendant, un employé de System76 a créé une extension non officielle permettant d’utiliser d’autres compositeurs, dont Niri

  • J’ai moi aussi hésité en passant de PaperWM à Niri. PaperWM évitait d’avoir à configurer les apps une par une, et les fonctions natives de GNOME (launcher, réglages, verrouillage, widgets audio/réseau, etc.) étaient très confortables, mais PaperWM avait aussi parfois des bugs redimensionnement de fenêtre ou des problèmes subtils de dimensionnement vertical, ce qui le rendait finalement assez délicat à utiliser. Au bout du compte, Niri était bien plus clair

  • Ce serait fantastique si COSMIC ajoutait simplement le tuilage. J’aime vraiment beaucoup COSMIC, c’est le seul élément qui lui manque

  • Je me demandais justement quelles étaient les différences avec COSMIC, donc c’était utile

• En ce moment, la popularité de Niri explose tellement que le développeur est surchargé. Si vous voulez contribuer, il vaudrait mieux sponsoriser Ivan ou aider à relire d’autres PR avant d’en ouvrir une vous-même. Niri comme Smithay se distinguent par leur grande qualité, et leurs fonctionnalités s’étoffent avec le temps sans problèmes critiques

  • Je me demande dans quelle mesure des non-spécialistes qui relisent des PR en amont peuvent vraiment aider. Au final, le mainteneur devra de toute façon toujours vérifier lui-même avant le merge, et du point de vue des contributeurs, voir des gens qui ne maîtrisent que superficiellement le sujet donner leur avis peut même être agaçant

  • Si vous utilisez Niri tous les jours, vous devriez vraiment montrer votre reconnaissance ; j’ai déjà fait un don. Je partage au passage mon setup, en espérant que cela inspire quelqu’un lien vers le setup

  • Si l’on utilise Hyprland, pourquoi faudrait-il passer à Niri ? Est-ce que la fonction de fenêtres infinies est son plus grand atout ?

  • Lien de sponsoring

• Sur MacOS, j’ai toujours tendance à tout mettre en plein écran et à basculer entre les fenêtres avec cmd-tab/cmd-backtick, et j’envie vraiment le workflow Linux en tiling. C’est frustrant de ne pas pouvoir recréer ce genre d’environnement sur MacOS, tout en étant bloqué par la politique de l’entreprise qui m’empêche aussi de passer à Linux. J’imagine que beaucoup de gens comprendront cette frustration de connaître un meilleur workflow sans pouvoir l’adopter

  • Depuis un mois, je porte komorebi sur MacOS ; la disposition défilante n’est pas au niveau de Niri, mais elle fonctionne bien sur les deux plateformes. vidéo1 vidéo2

  • Dans une situation similaire où je ne pouvais utiliser que MacOS, j’ai essayé d’exécuter Linux dans une machine virtuelle plein écran. Techniquement, cela restait du MacOS, donc l’IT n’y voyait rien à redire, et les politiques de sécurité passaient toujours. Certaines entreprises fournissaient même une licence VMware

  • Parmi les gestionnaires de fenêtres pour Mac, Aerospace était le meilleur

  • J’utilise le gestionnaire de fenêtres Yabai sur Mac ; c’est très bien avec un grand écran, mais sur un simple laptop je me retrouve juste avec quelques spaces et une ou deux fenêtres par espace, sans avoir trouvé de workflow vraiment satisfaisant

  • Je recommande flashspace. Quand les apps sont lancées en plein écran, si l’on assigne les workspaces à des touches, on peut y basculer instantanément sans animation

• La raison pour laquelle je n’avais pas essayé Niri, c’est que le fichier de configuration était limité à un seul fichier, ce qui était gênant pour maintenir un environnement légèrement différent selon plusieurs machines (par exemple en appliquant des réglages locaux ignorés par git). Mais récemment, deux PR importantes ont été mergées, permettant désormais des overrides/includes personnels comme dans cette PR connexe. Ce n’est pas encore sorti en release, mais j’attends ça avec impatience

  • Cette fonctionnalité a demandé des changements assez complexes pour être correctement implémentée, donc cela a pris du temps, mais maintenant qu’elle est enfin mergée, je suis très impatient

• Je me demande ce qu’un nouveau WM en tiling apporte de si intéressant, moi qui utilise xmonad depuis plus de 15 ans. Quant aux compositeurs Wayland, j’ai du mal à voir quels avantages ils ont au-delà de « tiling + Wayland ». En particulier, chaque fois que j’ai essayé Wayland autrefois, j’ai toujours rencontré des bugs critiques par rapport à X11, surtout avec Nvidia

  • J’ai retenté Wayland durant l’année écoulée sur un environnement Nvidia+Arch+Gnome3+Wayland, et aujourd’hui presque tout fonctionne sans problème ; Firefox, en particulier, est remarquablement fluide et efficace

  • Wayland a encore des problèmes quand on fait des choses particulières (par exemple, impossible de faire pivoter l’orientation d’une tablette graphique). Cela dit, Nvidia fonctionne bien à partir de la version 570 du pilote

  • La distribution Linux utilisée compte beaucoup. J’utilise Wayland depuis longtemps sur Fedora et je n’ai pas eu de gros problèmes, que ce soit sur des machines Intel ou Nvidia

  • J’ai eu une expérience similaire (avec, au milieu, un incident de rm qui m’a forcé à réécrire ma configuration) : j’ai utilisé xmonad de 2009 à 2023 avant de passer à Niri. Les raisons détaillées sont ici. Sous PopOS, avec 2x GTX 1080 et plusieurs écrans, tout fonctionne sans problème. Je recommande sans réserve

  • J’ai essayé Wayland sur un Asus Rog G14 + Nvidia 3060 et, contrairement à tout le scepticisme que j’avais, il a suffi de configurer drm.modeset pour que tout fonctionne immédiatement. Les deux écrans externes (un en HDMI, un en DP via USB-C) ont été reconnus sans problème. À part l’absence de prise en charge du daisy chain, j’en suis satisfait. C’est une expérience récente donc je n’ai pas encore couvert tous les cas, mais chez moi cela fonctionne mieux que X

• Je suis passé d’i3 à Niri il y a quelques semaines et j’en suis très satisfait. La manière dont on utilise les fenêtres et les workspaces correspond plus naturellement à mes habitudes. Je travaille projet par projet, un workspace par projet, et le fait de pouvoir ouvrir temporairement un terminal ou un navigateur à droite sans impacter ni réorganiser les autres fenêtres est extrêmement pratique pour les consultations ponctuelles ou l’exécution de commandes. Mon seul problème, c’est que maintenant j’ai vraiment envie d’un moniteur ultra-large

  • J’ai essayé Niri sur un écran de 49 pouces et j’ai arrêté à cause de problèmes, surtout avec la combinaison Nvidia+Wayland. Même sur une courte période, Niri s’adaptait plutôt bien aux grands écrans. En revanche, quand une seule app était ouverte, la fenêtre restait toujours collée tout à gauche de l’écran, ce qui n’était pas très agréable visuellement. Je ne sais pas s’il existe une fonction pour lancer les apps un peu plus à droite ou utiliser l’espace de manière plus libre. Je compte retenter l’expérience plus tard sur une machine AMD ; pour l’instant, Niri reste mon premier choix

• Un exemple appliquant le concept de Niri à Sway : scroll

• Hier, en réinstallant PopOS, je suis passé à Niri et je m’y suis adapté immédiatement de façon intuitive. Comme à l’époque où j’utilisais i3wm, je n’ai plus du tout besoin de me soucier du redimensionnement des fenêtres, et avec Niri il n’y a presque jamais besoin de réorganiser quoi que ce soit même quand les fenêtres s’accumulent dans le workspace, ce qui améliore énormément ma concentration. Ma config : RTX 3090, Pop OS 24.04 bêta, moniteur 4K de 43 pouces ; l’installation de Niri via cargo build a été facile, et pour lancer des apps X11 comme VS Code, Obsidian, Zoom ou Blender, il faut absolument installer xwayland-satellite

• Après avoir personnalisé Hyprland puis être revenu à GNOME à cause de plusieurs limitations (j’ai besoin de dizaines voire centaines d’onglets de navigateur, des extensions de tray, etc.), et comme à chaque montée de version GNOME casse la compatibilité des extensions, j’ai finalement décidé de quitter GNOME pour de bon. Cette fois, après avoir essayé River, QTile et Niri, je me suis fixé sur Niri et j’ajoute petit à petit moi-même les fonctionnalités dont j’ai besoin. Le regroupement dynamique des workspaces est intuitif et pratique, et les raccourcis clavier peuvent être configurés exactement selon mes goûts. Pour compléter l’environnement de bureau, j’utilise waybar et swaync. Je m’amuse aussi à écrire des scripts avec des outils d’automatisation comme Claude Code/Codex. Par exemple, je teste plusieurs idées comme niri-workspaces pour afficher l’activité de la fenêtre courante dans waybar, niri-workspace-names avec intégration fuzzel pour renommer les workspaces, ou encore un AltTab personnalisé. Ajouter des fonctions comme des miniatures live serait sans doute un projet plus ambitieux. Grâce aux nouveaux agents de code, il est désormais possible de personnaliser assez profondément son environnement même sans documentation détaillée

  • Pour tout ce qui concerne le basculement entre applications, niriswitcher peut aussi être utile