Niri 26.04 : compositeur Wayland à tiling défilant

 (github.com/niri-wm)
2 points par GN⁺ 3 일 전 | 1 commentaires | Partager sur WhatsApp
  • Le compositeur Wayland à tiling défilant gagne en maturité avec des améliorations sur le flou d’arrière-plan, le screencast, le rendu et le traitement des entrées
  • Le flou d’arrière-plan est intégré à la branche principale, ce qui permet aux fenêtres et éléments layer-shell prenant en charge ext-background-effect de demander un flou sans configuration niri supplémentaire, et il devient aussi possible de forcer le flou via des règles côté niri
  • Le screencast a été affiné à la fois sur les chemins PipeWire et wlr-screencopy, avec des corrections sur la gestion du curseur, le mode de démarrage du dynamic cast, la consultation IPC et l’arrêt forcé, ainsi que sur la copie multiple et la libération des ressources
  • La structure de rendu a été réorganisée d’un modèle basé sur des itérateurs vers un modèle push, ce qui a accéléré de 2 à 3 fois la construction des listes de rendu sur les machines principales, et jusqu’à 8 fois sur un ancien Eee PC, tout en réduisant l’usage mémoire
  • Des ajustements ont aussi été apportés au matériel ancien et aux environnements d’entrée, élargissant les usages réels : captures d’écran et screencasts sur d’anciens systèmes Intel, conflits entre IME et popups GTK 4, souris à haute fréquence de polling et mapping tablette, ainsi qu’accélération DMA-BUF dans niri imbriqué

Changements principaux

  • L’organisation GitHub a été déplacée du compte personnel vers niri-wm, et les projets liés ont aussi été réorganisés
  • Des changements liés au packaging sont également inclus
    • La version minimale prise en charge de Rust passe à 1.85
    • niri.service ne hardcode plus /usr/bin/ dans le chemin du binaire niri
    • La structure des fichiers de service dinit change : 3bfa4a7

Flou d’arrière-plan

  • Le flou d’arrière-plan arrive dans la branche principale, et les fenêtres comme les composants layer-shell peuvent demander un flou via le protocole ext-background-effect
  • Même si une application ne prend pas encore en charge ext-background-effect, il est possible d’activer le flou côté niri avec des window-rule et layer-rule
    • Les réglages détaillés et limitations sont récapitulés dans la documentation Window Effects
    • Le flou configuré dans niri nécessite un geometry-corner-radius correct
    • Cela ne fonctionne pas avec des formes de surface complexes
  • xray blur et flou classique sont proposés ensemble, avec xray blur activé par défaut
    • xray blur ne calcule le flou du fond d’écran qu’une seule fois, puis le réutilise comme une image statique, ce qui est bien plus efficace
    • Le recalcul n’a lieu qu’au changement du fond d’écran
    • Le gain d’efficacité est réduit avec des fonds d’écran animés
    • Un nouveau matcher layer permet de n’appliquer le flou classique qu’à certaines couches comme top ou overlay
  • La mise en œuvre du flou était suffisamment complexe pour nécessiter un changement de structure de rendu
    • Le flou classique relit les pixels déjà rendus en milieu de frame pour les flouter, puis reprend le rendu
    • xray blur nécessitait de transmettre la position des fenêtres dans tout le code de rendu pour découper correctement l’arrière-plan
    • Il fallait conserver dans Overview la propriété de ne pas rerendre l’overview, tout en prenant en charge xray blur
    • Il fallait aussi que cela fonctionne avec les fenêtres bloquées en screencast
  • Il est possible d’utiliser xray seul sans flou, et d’exploiter séparément le noise pour atténuer le banding du flou ainsi que l’effet de saturation
  • Un nouveau bloc popups permet d’appliquer transparence et effets d’arrière-plan aux menus popup dans une window rule ou une layer rule
    • Le rendu peut paraître étrange pour des formes qui ne sont pas des rectangles arrondis, comme les popups GTK 4 avec has-arrow=true
    • Les web apps et Electron n’utilisent pas les popups Wayland, donc niri ne peut pas les gérer
    • Les clients qui implémentent directement ext-background-effect peuvent gérer des formes de flou plus complexes

Include optionnel

  • Un include optionnel a été ajouté au config include
    • Utilisé comme include optional=true "optional-config.kdl", il n’échoue pas au chargement de la configuration si le fichier est absent
    • Si le fichier est absent, un avertissement est journalisé à chaque rechargement de la configuration, mais celle-ci continue d’être chargée
    • Si le fichier apparaît plus tard, le changement surveillé est détecté et un rechargement automatique est déclenché
    • Si le fichier existe mais contient une erreur de syntaxe, cela reste traité comme un échec de parsing
  • ~ dans les chemins d’include est développé vers le répertoire personnel
    • ~/file.kdl devient /home/user/file.kdl

Warp du pointeur et défilement

  • Lors d’un geste de défilement de la vue, le pointeur est désormais warpé d’un bord de l’écran à l’autre
    • Le comportement est similaire à Blender
    • Cela permet de continuer à faire défiler naturellement plusieurs fenêtres, même en démarrant près du bord du moniteur

Améliorations du screencast

  • Le screencast de niri a été amélioré aussi bien via xdg-desktop-portal-gnome via PipeWire que via wlr-screencopy

  • Gestion du curseur dans le screencast de fenêtre

    • Prise en charge des métadonnées de curseur dans PipeWire au lieu de dessiner directement le curseur dans les images vidéo
      • Le curseur n’apparaît pas dans les images vidéo, et l’icône du curseur ainsi que ses coordonnées sont envoyées dans un tampon séparé
      • Le consommateur, comme OBS ou un navigateur, dessine lui-même le curseur
    • Cela fonctionne à la fois pour la capture d’écran d’un moniteur et pour la capture d’une fenêtre
    • Dans la capture de fenêtre, le curseur n’est visible que lorsqu’il pointe réellement cette fenêtre ou l’un de ses popups
    • L’icône de glisser-déposer est également dessinée
    • Lors de l’implémentation, un problème de corruption mémoire dans PipeWire a aussi été mis au jour puis corrigé
    • Un décalage a aussi été constaté entre l’intention de PipeWire et l’implémentation côté consommateurs comme libwebrtc
    • Dans les environnements testés, tout fonctionne correctement
    • screenshot-window show-pointer=true permet aussi d’inclure le pointeur dans les captures de fenêtre

  • Changement de méthode de démarrage de Dynamic cast target

    • Dynamic cast target permet de changer immédiatement la cible du screencast via un raccourci clavier
    • Auparavant, il s’ouvrait au démarrage avec un flux vidéo d’un pixel noir 1×1
    • Désormais, le démarrage du flux vidéo est retardé jusqu’à la sélection de la première cible réelle
    • Cela permet d’éviter le bref problème de vidéo 1×1 dans Microsoft Teams

  • Cast IPC

    • Il est désormais possible d’inspecter les screencasts en cours via l’IPC
    • niri msg casts permet de voir les casts actifs
    • Il est possible de s’abonner aux cast events dans le event stream
    • L’objet Cast fournit le type, la cible actuelle et l’état actif
    • Les screencasts PipeWire fournissent un node ID, et wlr-screencopy fournit un ID de processus client
    • DankMaterialShell affiche déjà un indicateur de screencast via cet IPC
    • niri msg action stop-cast --session-id <ID> permet de forcer l’arrêt d’un screencast PipeWire

  • Limites et correctifs liés à wlr-screencopy

    • wlr-screencopy ne fournit pas de moyen robuste pour distinguer screencast et capture d’écran, ce qui impose quelques heuristiques
    • xdg-desktop-portal-wlr conserve en permanence un unique objet wlr-screencopy manager, ce qui rend difficile de savoir immédiatement quand cela se termine
    • Ces problèmes sont résolus par le nouveau protocole ext-image-copy-capture, mais il n’est pas encore intégré à niri

  • Autres correctifs de screencast

    • Correction d’un problème où le curseur était toujours inclus lors de la copie des damage même si le client wlr-screencopy ne le voulait pas
    • Correction du comportement lors de demandes simultanées de copies multi-images avec damage
    • Correction d’un problème où les données wlr-screencopy de niri n’étaient pas libérées dans certains cas, notamment quand le client se terminait
    • Réduction du nombre de tampons par défaut des screencasts PipeWire de 16 à 8
    • Réorganisation de l’ordre des champs de structure pour éviter un problème de use-after-free dans pipewire-rs
    • Correction d’un rendu où l’ordre en Z était incorrect pendant une image lorsqu’une cible de dynamic cast était changée en fenêtre

Animations et comportement des fenêtres

  • La synchronisation des animations est désormais plus précise
    • niri permet de configurer séparément chaque animation, mais les exécute de façon synchronisée lorsqu’elles doivent correspondre exactement
    • Les animations de redimensionnement de fenêtre sont synchronisées avec les animations de déplacement horizontal de vue qu’elles provoquent
    • Correction d’un problème où, lors de la sortie du fullscreen ou de l’état maximisé, la synchronisation du déplacement de vue manquait, la fenêtre revenait immédiatement et seul l’écran défilait lentement
  • Correction d’un problème où l’animation de déplacement horizontal d’autres fenêtres en tuiles était sautée sur certains trajets de glisser-déposer
    • Cela se produisait quand on faisait glisser une fenêtre maximisée pour la détacher, puis qu’on la remettait en mode flottant si elle était initialement flottante
    • Et à cause d’un chevauchement avec la logique de défilement des workspaces à gauche et à droite lors d’un glissement près du bord du moniteur
    • Commit de correction : df3f3979e936ed6800b4fbd55843bb0fe2554f15
  • Correction également d’un problème où, lorsqu’on tirait puis relâchait la colonne la plus à gauche d’un workspace, elle revenait à droite au lieu de sa position d’origine
  • La durée d’affichage des notifications d’erreur de configuration n’est désormais plus affectée par les réglages de ralentissement/accélération des animations

IME et popups

  • Contournement d’un ancien problème empêchant les champs de saisie des popups GTK 4 et les IME de fonctionner ensemble
    • Avec un IME comme Fcitx5 activé, il était impossible d’ouvrir des popups de saisie de texte
    • Le conflit venait du fait que le popup prenait le grab du pointeur et du clavier, tandis que l’IME utilisait lui aussi un grab clavier
    • niri abandonnait alors le grab du popup, ce qui provoquait souvent sa fermeture immédiate
    • Certaines vérifications ont été assouplies pour que cela fonctionne sans refondre entièrement la structure de Smithay
    • Les utilisateurs d’IME peuvent désormais faire des opérations comme renommer un fichier dans Nautilus

Glisser-déposer et périphériques d’entrée

  • Il est désormais possible d’annuler une opération de glisser-déposer en appuyant sur Escape
  • Plusieurs correctifs ont aussi été apportés aux périphériques d’entrée en général
    • Correction d’un problème de ralentissement progressif au fil du temps lors de l’usage d’une souris à haute fréquence avec hide-after-inactive-ms ou un daemon de surveillance d’inactivité
    • Avec libwayland-server v1.23 ou plus, augmentation de la taille du tampon Wayland afin qu’une fenêtre non réactive ne plante pas rapidement quand on déplace une souris à haute fréquence au-dessus d’elle
    • Ajout de l’option de tablette map-to-focused-output, qui permet de mapper vers la sortie actuellement focalisée au lieu d’une sortie unique prédéfinie
    • Correction d’un problème où, sur le pixel tout en haut du workspace, le curseur ne pointait pas toujours précisément la fenêtre maximisée
    • Correction d’un problème où Alt-Tab réagissait aux entrées souris avant d’être visible à l’écran
    • Le défilement on-button-down des trackballs fonctionne aussi dans l’overview
    • L’état de Num Lock est conservé même après le chargement d’une keymap .xkb personnalisée
    • Correction d’un problème empêchant totalement l’utilisation des périphériques d’entrée lors d’un démarrage depuis un autre TTY via tmux
    • Activation du chargement des plugins libinput

Profilage GPU et optimisation du rendu

  • Une intégration du profilage GPU a été ajoutée à Tracy, utilisé par Smithay et niri
    • Le travail consistant à soumettre des requêtes de timestamps GPU, à collecter les valeurs terminées et à les envoyer à Tracy a été intégré à Smithay : PR correspondante
    • Il est désormais possible de baliser les sections aussi bien pour les tâches GPU internes de Smithay que pour les tâches GPU propres au compositeur
    • Il est possible de suivre comment le rendu des buffers DRM et celui des buffers de screencast PipeWire se chevauchent dans une même frame
    • Sur les systèmes multi-GPU, il est aussi possible de voir une piste par GPU
    • Cela a permis de vérifier que les performances du blur n’étaient pas plus lentes que prévu, et de faciliter le diagnostic des dropped frames dus à des engorgements du rendu GPU
  • La méthode de construction des listes de rendu a été réorganisée, en passant d’une approche basée sur des itérateurs à une approche basée sur push
    • Auparavant, les éléments de rendu étaient composés sous la forme -> impl Iterator<Item = ...>
    • Cela entraînait diverses complexités liées aux branchements conditionnels, aux lifetimes, aux emprunts de &self, aux conflits avec &mut Renderer, aux allocations intermédiaires de Vec et aux frontières entre crates
    • La nouvelle structure consiste à faire recevoir à la fonction de rendu un push: &mut dyn FnMut(Element) dans lequel elle pousse les éléments
    • Les fonctions intermédiaires peuvent conserver la logique existante avec des closures qui encapsulent le push supérieur
    • Les Vec temporaires disparaissent et les problèmes d’emprunt aussi
    • Dans niri, l’avantage d’un arrêt anticipé des itérateurs n’était en pratique pas nécessaire
  • Ce refactoring accélère fortement la vitesse de construction des listes de rendu
    • Sur la machine principale, c’est 2 à 3 fois plus rapide
    • Sur un ancien Eee PC, c’est 8 fois plus rapide
    • La construction de la liste de rendu n’est pas le temps réel de rendu GPU lui-même, mais comme elle s’exécute souvent même sans redessiner l’écran, le gain est important
    • L’usage mémoire a aussi diminué, et les allocations dans le nouveau chemin se limitent désormais pour l’essentiel à l’extension du vecteur de sortie
    • Les motivations détaillées et le diff sont disponibles dans la PR

Prise en charge du matériel ancien

  • Il s’est avéré que la cause de l’échec des captures d’écran sur d’anciens portables Intel était une valeur d’enum OpenGL incorrecte dans Smithay, et cela a été corrigé : PR d’analyse de la cause
  • Les shaders de niri ont aussi été légèrement optimisés, ce qui permet même sur le GPU limité d’un très vieil ASUS Eee PC de faire fonctionner :
    • les animations de redimensionnement des fenêtres
    • les coins arrondis du compositeur

Autres améliorations

  • Correction d’une fuite de VRAM qui se produisait sur certains systèmes après la fermeture de certaines applications
  • Ajout du protocole ext-foreign-toplevel-list, ce qui facilite dans Quickshell et ailleurs l’association des objets de fenêtre Wayland avec les ID de fenêtre de l’IPC niri
  • En cas d’erreur de bind dupliqué dans la configuration, l’emplacement de la première définition du même bind est désormais aussi affiché
  • Affichage d’un curseur de saisie lors du déplacement d’une fenêtre avec Mod+LMB
  • Ajout de l’argument --path à niri msg action load-config-file, permettant de basculer à l’exécution vers un autre fichier de configuration
  • Le support DMA-BUF arrive dans niri imbriqué, ce qui permet au matériel accéléré de refonctionner après la suppression de wl_drm dans Mesa
  • Suppression du padding que niri ajoutait aux pop-ups layer-shell près des bords de l’écran
  • La configuration par défaut a aussi été modifiée
    • Mod+M : maximize-window-to-edges
    • Mod+Shift+R : switch-preset-column-width-back
  • Ajout du drapeau de débogage force-disable-connectors-on-resume, qui permet de forcer l’écran à devenir noir lors d’un changement de TTY ou d’une reprise après veille
  • Correction pour que les coins des fenêtres soient correctement à angle droit en fullscreen fenêtré
  • Correction d’un problème où l’écran continuait à être redessiné en permanence tant que l’overview était ouverte
  • Légère correction du rendu de la bordure en dégradé relative-to=workspace-view pendant un glisser interactif
  • Ajustement du rendu du raccourci diaeresis dans la boîte de dialogue Important Hotkeys
  • Correction de la description de expel-window-from-column dans niri msg action afin qu’elle corresponde au comportement réel, à savoir expulser la fenêtre du bas
  • Correction de plusieurs panic pouvant survenir quand un client essayait d’utiliser une sortie récemment retirée
  • Correction d’un problème où clip-to-geometry provoquait un rendu corrompu lorsqu’il était utilisé avec des clients attachant des buffers y_invert
  • Correction de la compilation sur OpenBSD
  • niri imbriqué configure désormais l’app-id de sa propre fenêtre
  • Lorsqu’un nouveau GPU est branché, le paramètre de débogage ignore-drm-device est réévalué, ce qui permet aussi d’utiliser les liens symboliques /dev/dri/by-path/

Intégration des mises à jour de Smithay

  • Les mises à jour de Smithay apportent aussi plusieurs améliorations de fond
    • La sélection automatique du GPU a été améliorée sur certains appareils comme les Mac ARM
    • Asahi et Pinephone peuvent désormais fonctionner directement sans configuration manuelle de render-drm-device
    • Le fonctionnement de certains clients layer-shell comme wl_shimeji a été amélioré
    • La prise en charge des docks dont l’EDID de l’écran se charge tardivement a été améliorée
    • Les captures d’écran et screencasts fonctionnent sur les anciens systèmes Intel
    • Correction d’un problème où une ancienne sortie restait présente lors du débranchement d’un dock USB-C pendant la veille
    • Correction d’un panic de zxdg_exporter_v2 sur certains clients
    • Correction d’une fuite mémoire chez les clients qui ne détruisaient pas explicitement le protocole du presse-papiers
    • Correction de panic liés aux text-input content hint et purpose apparus avec les versions de développement de GTK 4.23
    • Les performances globales, ainsi que le drag-and-drop, la saisie de texte IME et le multi-GPU, ont aussi été améliorés

À lire aussi

1 commentaires

 
GN⁺ 3 일 전
Commentaires sur Hacker News

  • J’aime tellement Niri que, depuis que j’y suis passé il y a environ 5 mois, j’ai l’impression que c’est l’une des meilleures décisions que j’ai prises ces dernières années en quittant Windows
    J’éprouve une vraie gratitude envers l’auteur
    Mes dotfiles incluaient à l’origine des scripts d’installation pour la configuration d’outils CLI, le changement de thèmes, etc., et maintenant ils prennent aussi complètement en charge Niri sur les distributions de la famille Arch
    Si vous voulez essayer rapidement un nouvel environnement de bureau, https://github.com/nickjj/dotfiles est un très bon point de départ
    Je l’utilise à la fois sur mon desktop principal et sur mon laptop de voyage

    • Pareil pour moi, et la combinaison écran ultrawide incurvé + Niri fonctionne particulièrement bien
    • Il faut aussi absolument jeter un œil à Nirimod
      Ce n’est pas officiel, mais c’est vraiment excellent
    • Omarchy a ajouté un basculement du mode scrollable par workspace de ce genre
      En appuyant sur Win/Cmd + L, on bascule entre tiling et scrolling, et en ce moment je m’en sers vraiment souvent

  • C’est grâce à Niri que j’ai découvert pour la première fois la gestion de fenêtres basée sur le scroll, et ça a tout de suite fait sens
    Récemment, OmniWM sur Mac a ajouté un mode d’émulation complet de Niri par workspace, et heureusement c’est aussi compatible avec Sequoia, donc c’est devenu immédiatement mon gestionnaire de fenêtres principal
    [1] https://github.com/BarutSRB/OmniWM

    • Paneru est un nouvel outil sur macOS conçu précisément pour imiter Niri
    • Même chose pour moi
      Quand j’ai découvert l’approche de Niri pour la première fois, j’ai vraiment adoré, et j’ai continué à chercher quelque chose de similaire sur Mac
      C’est de loin la meilleure implémentation que j’aie utilisée jusqu’ici, et même s’il y a clairement quelques petites quirks, dans mon cas c’est largement utilisable comme daily driver
      Les colonnes à onglets sont particulièrement excellentes
      Bravo au mainteneur et aux contributeurs

  • Si vous utilisez un Mac, je recommande OmniWM
    Il propose non seulement des layouts de style Niri, mais aussi des layouts plus proches de Hyprland, et ça a rendu mon travail sur macOS bien plus agréable
    https://github.com/BarutSRB/OmniWM
    J’en avais déjà parlé quand je venais de commencer à l’utiliser, mais après l’avoir gardé plus longtemps, je le trouve vraiment très bon et je le recommande vivement

    • Désolé, mais la vidéo de démo est au niveau de la pire vidéo de démo que j’aie jamais vue de ma vie
      Je ne pense pas que qui que ce soit ait envie d’essayer ce logiciel après avoir vu ça, et même en étant déjà utilisateur, ça donnerait presque envie de le désinstaller

  • J’utilise l’extension PaperWM pour GNOME, et Niri semble probablement en avoir tiré son inspiration
    C’est clairement une manière de travailler intéressante, mais dès qu’il y a plus de 3 fenêtres sur un workspace, ça commence à me sembler un peu fastidieux, donc je n’en suis pas tombé totalement amoureux
    Cela dit, je l’utilise sérieusement, et comme c’est une extension GNOME, c’est agréable de pouvoir conserver le reste de l’environnement GNOME sans avoir à trop configurer

    • J’ai voulu passer à Niri pendant un moment, mais l’ajustement de toute la configuration annexe me prenait toujours plusieurs jours
      Il fallait tout gérer, de la top bar au délai d’inactivité en passant par les notifications
      Mais j’ai récemment découvert qu’il existait des desktop shells pour Wayland, et qu’ils fournissent, sans trop d’effort, l’essentiel de ce qu’on attend d’un environnement comme GNOME
      Ils incluent des boîtes de dialogue de configuration, une app tray, le monitoring des ressources, et même une top bar
      En ce moment j’utilise dank material shell, et le fait de pouvoir combiner librement desktop shell et compositor est vraiment génial
    • Pareil pour moi, et j’apprécie le fait que PaperWM soit une extension GNOME non intrusive
      Mon workflow s’est globalement amélioré, mais ça m’a aussi permis de supprimer deux ou trois autres extensions comme desktop grid

  • Je me suis complètement habitué au flux d’un tiling WM où l’on passe rapidement entre plusieurs workspaces fullscreen dédiés, avec une gestion des fenêtres uniquement au clavier
    En général, j’ai une seule app par workspace, ou bien un terminal avec tmux, et seulement occasionnellement deux apps côte à côte
    Je suis vraiment curieux de savoir comment le modèle mental change chez les gens qui passent à Niri depuis un workflow similaire

    • J’ai toujours utilisé des workspaces par activité/projet dans KDE, GNOME et Niri
      Un workspace avec Steam et un wiki de jeu, un workspace avec Emacs et un navigateur de documentation, un workspace avec Godot et des apps de développement de jeux, etc.
      Ce qui est bien avec Niri, c’est qu’on ne ressent presque aucune pression à devoir fermer quelque chose sous prétexte qu’il y a trop de fenêtres
      C’est assez facile de tout séparer et organiser
      Je ne vois pas trop pourquoi on utiliserait des workspaces par application
      Je n’aime pas non plus avoir dans un seul Firefox un mélange d’onglets pour le travail et les loisirs
    • J’ai été utilisateur de tiling pendant assez longtemps, avec une configuration similaire
      awesome, qtile, un peu de xmonad pendant un temps, puis i3, ensuite sway en passant à Wayland, et aussi un peu de hyprland
      Le problème que je rencontrais toujours, c’est qu’au-delà de 3 fenêtres, une disposition horizontale ne fonctionnait plus très bien, et les divisions verticales devenaient trop petites
      En revanche, j’avais souvent envie d’ouvrir une nouvelle fenêtre à côté de ce que j’étais en train de lire, ou d’afficher un graphique ipython à côté d’un terminal
      À chaque fois, il fallait soit passer à un layout empilé, soit déplacer ça vers un nouveau workspace, ce qui créait pas mal de friction et cassait sans cesse mon flux de travail à cause de la gestion des fenêtres
      Dans Niri, j’ouvre simplement une nouvelle fenêtre et elle apparaît à l’endroit voulu, tandis que les autres restent à gauche et à droite, accessibles par scroll
      Mon workflow est maintenant un peu plus désordonné qu’avant, mais c’est justement ce qui me plaît
      Les tiling WM classiques demandent de l’ordre et le rendent facile, mais avec Niri il n’y a pas vraiment besoin de ranger
      Quand il m’arrive de ne pas retrouver tout de suite une fenêtre, j’utilise l’overview, et j’ai aussi ajouté une recherche de fenêtres avec rofi
      Au début, je gardais des workspaces nommés par habitude de l’époque sway, mais ce n’est plus le cas aujourd’hui
    • Je suis arrivé depuis KDE avec quasiment le même workflow
      Le workspace 1 était un terminal fullscreen avec zellij, le 2 un navigateur, le 3 environ deux apps de chat, et je passais de l’un à l’autre avec des raccourcis
      Au début, j’ai utilisé Niri parce que c’était plus léger et différent de Plasma, mais maintenant mon workflow a aussi un peu changé
      La plupart des fenêtres restent utilisées en taille écran, et j’organise encore de façon similaire, avec 1 pour le développement, 2 pour le navigateur et parfois un lecteur mail, 3 pour les apps de chat
      Mais j’ouvre bien plus souvent une nouvelle fenêtre de terminal pour taper de courtes commandes ou laisser tourner des tâches longues
      Sous KDE, ces fenêtres restaient empilées derrière ; maintenant elles se placent côte à côte dans le workspace 1
      Avec le recul, le fait de passer de l’une à l’autre avec Alt-Tab me paraît désormais assez frustrant, alors que naviguer avec Super-hjkl est bien plus léger
      Bien sûr, ça dépend des personnes, mais le fait que les fenêtres soient placées à côté plutôt que superposées rend le workflow plus fluide
    • En réalité, cela ressemble davantage à une combinaison de fullscreen et de workspaces qu’à du tiling
      Avec un WM à tiling manuel comme i3 ou sway et un grand écran, on peut diviser l’écran en plusieurs zones de travail et placer plusieurs apps par rôle dans chaque zone, ce qui réduit le nombre de workspaces nécessaires
      Le scrolling suit une logique proche mais différente, et c’est particulièrement bien adapté quand la flexibilité compte sur les petits écrans
    • Un workspace par application n’a pas vraiment de sens dans un tiling WM selon moi
      Ce workflow convient mieux à un floating WM
      Le vrai avantage d’un tiling WM, c’est justement de réellement disposer les fenêtres en tuiles, et pour moi la sainte trinité navigateur·éditeur·terminal est essentielle
      Et il faut pouvoir se déplacer spatialement avec super+hjkl ou les flèches
      C’est pourquoi des workspaces par projet me semblent bien plus naturels, et plus fidèles à l’esprit d’un tiling WM
      Niri fait cela bien mieux, car il ouvre les nouvelles fenêtres à droite sans casser le layout actuel
      Par exemple, on peut ouvrir un PDF et passer facilement à cette nouvelle fenêtre tout en conservant l’organisation existante

  • Voici des liens liés
    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)

  • Si vous voulez essayer les dots NNN (Niri-Nix-Noctalia), vous pouvez reprendre mon flake
    https://github.com/MostlyKIGuess/nix-flake-public

    • J’ai utilisé des window managers pendant des années, mais je suis finalement revenu à un environnement de bureau complet à cause de la barrière que représente le fait de devoir aussi configurer manuellement tout ce qui est en dehors du WM
      Rien que le mode sombre demandait déjà beaucoup de travail, et Noctalia semble exactement aller dans le sens que je voulais
      Merci de l’avoir mentionné

  • J’utilise la branche wl-only de mangowm (basée sur wlroots 0.20)
    Ça consomme bien moins de ressources, il y a plus de layouts, et il y a moins de problèmes
    Niri semble avoir de meilleurs effets visuels, mais ça vaut clairement le coup d’essayer
    Si vous avez besoin du HDR, il faut encore attendre
    https://github.com/mangowm/mango

    • Je me demande de quels problèmes il y en aurait moins
      Dans mon cas, Niri a été vraiment rock solid

  • On dirait qu’un génie russe a fini par faire quelque chose de meilleur que 100 millions de dollars de tokens Claude
    Ce n’est absolument pas une forme de folie collective, donc apparemment tout le monde devrait juste acheter du SPY

    • Franchement, ça a vraiment l’air d’être un génie
      Rien qu’en lisant les notes de version, on dirait presque une œuvre d’art

  • Fin de l’année dernière, je suis passé à Niri après plus de 10 ans sur i3
    Le scroll horizontal qui n’est pas limité par la taille du moniteur, et le nombre de workspaces qui n’est pas limité par le nombre de raccourcis configurés, donnent une vraie sensation de liberté
    Le niveau de finition graphique est aussi très bon
    Mon seul regret qui reste, c’est que xwayland-satellite, la couche de compatibilité X, ne prend toujours pas en charge le drag and drop entre les applications X et Wayland
    [1]: https://davidyat.es/2026/01/28/niri/
    [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

    • Je suis dans un cas assez similaire
      Avant, j’avais l’habitude de toujours mettre les mêmes choses dans les mêmes workspaces, donc c’était facile à mémoriser, mais maintenant la disposition finit par se disperser un peu partout
      Et le scratch me manque vraiment beaucoup
      J’imagine qu’avec un peu plus de travail sur la configuration, ce serait réglé, mais je n’ai pas encore eu envie d’y consacrer ce temps