Rift - gestionnaire de fenêtres en mosaïque pour macOS

• Gestionnaire de fenêtres en mosaïque open source utilisable sur macOS, en cours de développement avec un accent sur les performances et la facilité d’utilisation
• Fonctionne sans désactiver la protection de l’intégrité du système (SIP) et fait partie des rares gestionnaires de fenêtres compatibles avec l’option macOS « Displays have separate Spaces »
• Prend en charge divers styles d’agencement similaires à i3/sway et bspwm
• Offre une intégration naturelle avec l’environnement natif de macOS, comme la navigation entre espaces de travail façon Mission Control et les gestes du trackpad
• Met l’accent sur les performances d’animation et l’expérience utilisateur, avec comme points forts le hot reload de la configuration et les fonctions d’intégration avec des programmes externes
• Reprend certains atouts d’Aerospace, un gestionnaire de fenêtres en mosaïque existant pour macOS, notamment en matière de performances et de flexibilité, tout en visant des fonctions supplémentaires comme la prise en charge des animations et la possibilité d’utiliser un seul écran en plein écran dans une configuration multi-écrans

Fonctionnalités principales

• Plusieurs styles d’agencement : prise en charge d’une disposition des fenêtres en grille comme dans i3 ou sway, ainsi que d’un partitionnement binaire de l’espace à la manière de bspwm
• Icône dans la barre de menu : affiche visuellement tous les espaces de travail ainsi que l’état de l’agencement dans chacun d’eux
• Navigation façon Mission Control de macOS : permet de gérer facilement et visuellement le passage d’un espace de travail à l’autre
• Propose le changement automatique du focus avec la souris et le relèvement automatique des fenêtres
• Permet d’échanger la position des fenêtres lors d’un glisser-déposer, avec des animations fluides
• Avec les gestes du trackpad, il est possible de changer d’espace de travail comme dans l’expérience native de macOS
• Prend en charge les modifications de configuration à chaud (hot reload), ce qui facilite fortement la configuration en temps réel
• Prend en charge l’interface avec des programmes tiers comme Sketchybar ainsi que l’intégration via CLI ou mach port
• Peut envoyer des signaux (Signals) vers l’extérieur lors d’un changement d’espace de travail ou d’une modification de fenêtre, via la CLI ou une connexion mach

• Développé à 100 % en Rust

[GN⁺]

Commentaires Hacker News

• J’ai énormément utilisé i3 à une époque. i3 est extrêmement flexible et offre une grande liberté de configuration, donc on peut faire bien plus que simplement déplacer des fenêtres. Mais depuis que je suis passé sur Mac, je n’ai pas trouvé de gestionnaire de fenêtres en tuiles à la fois riche en fonctionnalités et stable. J’ai essayé plusieurs options et, aujourd’hui, j’utilise simplement Rectangle. Rectangle n’est pas vraiment un gestionnaire de fenêtres ; il fournit juste des raccourcis pour déplacer facilement les fenêtres à gauche/droite/haut/bas ou en divisions 3/4/6. Ça couvre environ 80 % de mes usages, je n’ai pas besoin de configuration personnalisée, et il n’y a pas de comportement inattendu, donc j’en suis très satisfait. En vieillissant, j’ai aussi plus de mal à consacrer du temps à toutes sortes de réglages personnalisés. Site officiel de Rectangle

  • La fonctionnalité que j’aime vraiment dans Rectangle, c’est le mode todo. Je ne m’en sers pas pour gérer mes tâches, mais pour épingler une certaine fenêtre afin qu’elle soit toujours visible, et tous les raccourcis globaux des fenêtres s’ajustent automatiquement en conséquence, ce qui est vraiment pratique
  • Je suis très reconnaissant que Rectangle prenne en charge l’option de raccourcis de Spectacle. Peut-être qu’un jour j’apprendrai les raccourcis par défaut, mais pour l’instant ils sont déjà bien ancrés dans ma mémoire musculaire, donc je continue comme ça
  • La combinaison Rectangle + Apptivate a mis fin à des années de recherche d’un remplaçant à i3. Déplacement des fenêtres avec Rectangle, bascule entre les fenêtres avec super+numéro via Apptivate — on retrouve exactement les mêmes mouvements que sur i3
  • Expérience similaire ici, sauf que j’utilise Divvy au lieu de Rectangle. Site officiel de Divvy
  • Je recommande Rectangle. La transition de Linux vers Mac a été bien plus facile grâce à lui

• Sur des écrans 5k/6k, le tiling classique atteint ses limites — les fenêtres deviennent beaucoup trop grandes. C’est pourquoi je pense qu’une app comme moon est bien meilleure. Sous Windows, il n’existe pas d’app équivalente à Moom, donc j’utilise un gestionnaire de tuiles comme komorebi. En tant que personne qui passe d’un système d’exploitation et d’un appareil à l’autre, je trouve dommage que rift ne prenne pas en charge des raccourcis universels du type alt+hjkl. Sur des moniteurs ultra haute résolution ou ultrawide, ce type d’agencement de fenêtres me semble indispensable (komorebi le prend en charge)

  • Si le schéma ASCII que tu as collé s’affiche mal, les blocs de code sont rendus comme du code sur HN si on les indente avec quatre espaces
  • Il paraît que komorebi arrive bientôt aussi sur macOS vidéo de présentation de komorebi sur macOS

• Ça peut être insuffisant pour beaucoup de monde, mais pour quelqu’un comme moi, qui utilise surtout une seule fenêtre sur Mac, ou deux écrans seulement quand je branche un moniteur externe, cette fonctionnalité de base suffit largement guide officiel Apple sur le split des fenêtres dans macOS (je ne suis pas un gros utilisateur de tiling)

  • Je me demande si cette fonctionnalité n’était disponible que sur les Mac Tahoe. Je n’en avais aucune idée jusqu’ici
  • Je ne savais absolument pas que cette fonctionnalité existait — merci pour l’info

• Si le plein écran et les gestes du trackpad paraissent si séduisants sur macOS, c’est parce que, dans la plupart des cas, on travaille dans une seule fenêtre. Mais quand il faut afficher en même temps terminal, éditeur, outils de développement du navigateur, logs et documentation, la prévisibilité de la disposition devient vraiment essentielle. Les outils de tiling ne servent pas seulement à mettre deux fenêtres côte à côte, ils permettent aussi de

  • réduire fortement le coût du changement de contexte (changement/réorganisation des fenêtres uniquement au clavier)
  • dupliquer des dispositions de travail fréquentes selon les projets
  • exploiter bien plus utilement les écrans ultra haute résolution grâce à des découpages précis
    Sur Mac, je couvre environ 80 % de mes besoins avec Rectangle ou Moom, et j’utilise Aerospace ou Rift pour le reste. Dès que le nombre de fenêtres ou la fréquence des bascules augmente, l’utilité d’un gestionnaire de fenêtres en tuiles devient évidente

• J’ai un temps voulu créer mon propre gestionnaire de fenêtres, mais j’ai vite abandonné parce qu’il n’y a pas de vraie API appropriée sur macOS. En pratique, il faut bricoler avec l’API d’accessibilité. Ce projet aussi utilise des bindings Objective C et l’API d’accessibilité, donc je suis curieux de savoir comment se passent le débogage et l’implémentation des fonctionnalités, ou quels outils ont surtout été utilisés

  • Je pense que le framework d’accessibilité est bien trop bien conçu pour être qualifié simplement de « bricolage ». Ces derniers mois, j’ai créé un projet similaire en Rust en manipulant divers bindings de frameworks macOS, et ce n’est pas si effrayant. Côté environnement de développement, Rust et rust-analyzer suffisent, avec la documentation Apple et celle de objc2 ouvertes ; pas besoin d’une configuration complexe du style XCode

• Moi aussi, j’ai récemment traversé une longue séance de yak shaving pour régler Aerospace exactement comme je le voulais. Je me demande comment les autres gèrent le grand nombre de conflits entre raccourcis. Comme j’ai l’habitude des combinaisons hjkl, j’ai toujours envie de tout mapper dessus, mais la fonctionnalité modale d’Aerospace résout au moins une partie du problème. Au final, comment est-ce que vous configurez ça ?

  • En général, j’ai l’impression que les gens s’en accommodent sans vraie solution. Chez moi aussi, les conflits de raccourcis apparaissent vite à l’usage. Après environ un an avec Aerospace, j’ai tout caché derrière alt+space comme touche leader. Je garde quelques alt-raccourcis dans le mode normal d’Aerospace, avec {hjkl} pour déplacer la fenêtre, et je gère le reste dans des modes séparés (par exemple des modes « go-to » et « move-to » pour se déplacer rapidement vers des fenêtres via lettres/chiffres). Avec zellij/tmux dans le terminal, ça donne l’impression d’une extension de l’ergonomie à base de leader key, et j’en suis satisfait. Une difficulté toutefois : Aerospace cache les fenêtres après un changement d’écran, donc je passe souvent du temps à les chercher dans un coin en bas
  • J’ai essayé Aerospace, mais sa configuration par défaut assigne les 26 combinaisons alt+lettre à des workspaces distincts, ce qui casse tous les raccourcis de type emacs disponibles dans les applications. Il n’y a même pas de tutoriel sur la configuration par défaut ou l’usage, juste une longue liste de commandes. J’ai récemment déjà pas mal souffert avec des environnements Linux comme sway et hyprland (y compris sur des sujets de bootloader Linux et de chiffrement de disque), et malgré ça, j’ai rarement vu un logiciel aussi peu accueillant. Du coup j’ai supprimé Aerospace et je considère Rift comme prochain candidat, ou alors je finirai peut-être par implémenter mon propre gestionnaire de fenêtres — parce qu’au fond, les gestionnaires de fenêtres en tuiles relèvent souvent de cette logique de compromis personnel : « je vais fabriquer moi-même exactement ce qu’il me faut »
  • J’utilise un schéma similaire avec Karabiner : j’ai remappé la touche Option droite de mon clavier externe en Option+Shift (A1), et la touche Control droite en Control+Option+Shift (A2). Dans la config Aerospace, le déplacement du focus se fait avec A1+hjkl, le déplacement des fenêtres avec A2+hjkl. Le changement de workspace avec A1+ui, et le déplacement des fenêtres entre workspaces avec A2+ui. Le changement d’écran (moniteur) avec A1+m, et le déplacement d’une fenêtre vers un autre écran avec A2+m. Ce sont en pratique les raccourcis que j’utilise le plus, et quand il y a conflit entre applications, je modifie les raccourcis de l’application concernée pour l’éviter. On pourrait encore étendre le système, mais même sous cette forme ça fonctionne déjà très bien
  • J’utilise les raccourcis meh (control+alt+shift) et hyper (control+alt+shift+command). J’ai mappé un appui long sur caps lock vers meh, et un appui bref vers esc. Ça m’a permis de concentrer énormément de raccourcis sous une seule main. Par exemple, meh+numéro pour changer de space, meh+space pour une hot window de terminal, et meh+hjkl aussi pour le focus des fenêtres

• Avec Hammerspoon, on peut créer son propre gestionnaire de fenêtres. J’aime bien l’approche modale proposée par Divvy (basculer de disposition avec des touches de commande uniques), mais malheureusement le projet n’est plus maintenu. J’ai donc créé moi-même un gestionnaire de fenêtres modal avec OpenAI Codex code source du gestionnaire de fenêtres pour Hammerspoon. Ce serait sympa de partager ce genre d’approche !

  • J’utilise aussi divvy depuis longtemps, et je n’avais aucune idée que le projet n’était plus maintenu… Cela dit, il fait déjà tout ce dont j’ai besoin, donc ça ne me gêne pas. S’il y a des fonctionnalités que tu aimerais voir ajoutées, ça m’intéresse de savoir lesquelles
  • Moi, j’ai couvert tous mes besoins avec MiroWindowsManager (plugin Hammerspoon). Grâce à trois modes de division par chord, je peux placer n’importe quelle fenêtre exactement dans la zone voulue avec de simples raccourcis. En quelques secondes, j’obtiens vraiment la disposition que je veux

• Pour un utilisateur de trackpad MacBook, rien n’écrase Swish, quelle que soit l’autre app Site officiel de Swish

  • C’est vrai que le nom « highly opinionated » lui va bien ;). Cela dit, la raison pour laquelle je continue à préférer Divvy, c’est que mes raccourcis clavier personnalisés fonctionnent toujours pareil, que j’utilise le trackpad ou un clavier externe. Site officiel de Divvy

• Quelqu’un a déjà configuré ça avec un nix flake ? Je teste différents gestionnaires de fenêtres depuis yabai, et avec Aerospace j’ai parfois des ralentissements, peut-être liés à la gestion des événements, quand je l’utilise surtout pour l’affichage joli des workspaces avec sketchybar. Je me dis que j’essaierai peut-être celui-ci (rift) ensuite

  • Pour info, c’est ici repo du nix flake pour rift

• Je ne comprends pas pourquoi on aurait besoin d’un gestionnaire de fenêtres en tuiles sur macOS. À quelle fréquence a-t-on vraiment besoin de mettre des fenêtres côte à côte ? Dans la plupart des cas, il suffit de lancer les apps en plein écran et de changer de fenêtre avec un swipe à quatre doigts, non ? J’aimerais bien que quelqu’un me convainque

  • Très souvent, en fait. Slack sur le quart droit, et le reste varie entre navigateur/terminal/IDE selon les besoins. Souvent aussi navigateur + tail de logs, avec parfois du multi-view ou un terminal à l’intérieur même de chaque app. Et il m’arrive fréquemment d’afficher des pages du navigateur côte à côte
  • Je ne dirais pas qu’un gestionnaire de tuiles est « nécessaire ». Mais peut-être que le « plein écran + swipe à quatre doigts » te convient surtout à toi, personnellement. Moi, j’ai désactivé presque tous les gestes, animations et multiples bureaux (spaces). Le passage d’une app plein écran à l’autre est bien trop lent, et pour atteindre l’app voulue, il faut souvent enchaîner plusieurs swipes. Je déteste devoir calculer mentalement l’ordre des apps et combien de fois je dois balayer. Je veux ouvrir immédiatement l’app que je veux, sans délai
  • Ce n’est pas macOS, mais j’imagine que c’est pour des raisons similaires à celles du tiling sous Linux. Quand on n’utilise que l’écran du portable, le plein écran est préférable, mais plus l’écran est grand, plus il y a de raisons d’avoir plusieurs fenêtres côte à côte. Documentation/e-mail, éditeur/terminal/VCS, code/documentation, template/web, comptabilité/banque, gestion de fichiers, etc. Il y a beaucoup de tâches où l’on doit voir plusieurs applications en même temps, et le tiling est alors bien plus productif
  • Il y a clairement des moments où c’est agréable d’avoir plusieurs fenêtres ouvertes côte à côte. Par exemple pour des usages comme navigateur web / documentation / IDE, ou quand une seule app n’a pas besoin d’occuper tout l’écran. En réalité, la plupart des applications n’ont pas besoin d’être en plein écran ; parfois, un quart d’écran est même plus confortable. Moi, j’utilise souvent plein écran + bureaux virtuels au quotidien, mais ça dépend vraiment du travail à faire
  • Avant, j’utilisais beaucoup les spaces (changement de bureau), mais sur un grand moniteur, il est finalement plus pratique d’avoir tout affiché sur un seul écran. J’utilise trois moniteurs de 32 pouces (ceux de gauche et de droite en orientation verticale) et, à part l’IDE, je n’utilise presque jamais le plein écran. Le split revient toujours à avoir plusieurs petits écrans en même temps, ce qui est simple et efficace, sans avoir à chercher dans quel bureau se trouve telle fenêtre. Chrome en particulier, quand il est ouvert sur plusieurs spaces, fait souvent que cmd-tab ne sélectionne pas la bonne fenêtre, et il faut aller la retrouver à la main, ce qui est pénible. À l’inverse, quand je n’utilise que le laptop, l’écran est petit, donc je gère plutôt les fenêtres via les espaces virtuels. Slack, plusieurs Chrome, terminal, IDE, postman, datagrip, etc. : je peux basculer vers n’importe quelle app avec un seul raccourci, sans changer tout l’écran. C’est comme avoir huit écrans physiques toujours ouverts, ce qui maximise vraiment la productivité. Avec r-cmd, je peux me concentrer sur chaque app très rapidement. Comme je n’ai pas besoin de me promener entre les bureaux virtuels, tout est aussi beaucoup plus facile à retrouver