ハクソク

世界を動かす技術を、日本語で。

Niri 26.04: スクロール可能なタイル配置のWaylandコンポジタ

2026年4月26日原文(github.com)

概要

  • niri は、スクロール可能なタイル型Waylandコンポジタ
  • ウィンドウは右方向に無限に続くカラムで配置、既存ウィンドウのリサイズなし
  • GitHub組織 への移行、関連プロジェクトやアートワークも集約
  • Blur（ぼかし）機能 やポップアップへの背景効果など、多数の新機能追加
  • Screencasting や設定ファイルのオプションincludeなど、利便性向上

niriの概要とGitHub組織移行

  • niri は、Wayland上で動作するスクロール可能なタイル型コンポジタ
  • ウィンドウは右方向に無限に連なるカラムで配置、 新規ウィンドウ追加時も既存ウィンドウのリサイズなし
  • プロジェクトは 個人アカウントからGitHub組織 へ移行、権限管理やコントリビューションのしやすさ向上
  • awesome-niriリスト や新たなアートワークリポジトリ（@Vortriz, @bluelinden, @HumpityDumpityDumberらが貢献）も組織に集約
  • niriリポジトリは 20,000スター を突破

開発体制と関連プロジェクト

  • issue triage 対応や質問対応で@Sempyosに謝意
  • アートワークリポジトリには バッジや壁紙、@Duncan-Rose制作の3D作品も公開
  • awesome-niri リストで関連プロジェクトを紹介

主要な技術的変更

  • Rust最小バージョン は1.85に更新
  • niri.service はバイナリパスのハードコードを廃止（@Axlefublrによる修正）
  • dinitサービスファイル の再構成（@markK24）

Blur（ぼかし）機能の実装

  • 最も要望の多かった機能 「Blur」がついにメインラインに統合
  • ext-background-effect Waylandプロトコル でウィンドウやlayer-shellがぼかしを要求可能
  • 既に多くのアプリ・ツールキットが対応（Material Shell, Noctalia, Vicinae, foot, kitty, Ghostty, Quickshell, winitなど）
  • niri config からも個別にぼかしを設定可能
    • 例：Alacrittyやfuzzel launcherの背後にblur適用
  • xray blur と通常blurの2種類を実装、デフォルトは高効率なxray blur
    • xray blurは壁紙を一度だけぼかして再利用するため、描画コストが低い
    • 通常blurはフレームごとに描画内容をぼかす方式
  • layer-rule で特定レイヤーのみ通常blurを適用可能

Blur実装の技術的課題

  • 単なるアルゴリズム以上に ウィンドウ背景効果全般の設計・効率化 が大きな課題
  • xray/non-xray でレンダリングアーキテクチャが大きく異なる
  • Smithayのレンダリング大規模リファクタリング（@Drakulixに感謝）
  • Overview機能 との両立や、スクリーンキャスト時の情報漏洩防止にも対応
  • blur無しのxrayやノイズ・彩度効果 も個別に設定可能

ポップアップメニューへの効果適用

  • popupsブロック でポップアップメニューにもblurや透明度を設定可能
    • 例：Loupeアプリのポップアップにblurとopacityを付与
  • Wayland pop-up を使わないElectron等には未対応、GTK 4では形状による制約あり

設定ファイルのoptional include

  • optional include で存在しないファイルもエラーにならず読み込み可能
    • 例：NixOSでの不変設定やローカル上書き用途
  • optional=true指定時、ファイルが無いときはログに警告のみ
  • ~（チルダ）始まりのパス展開 もサポート
  • @johnrichardrinehart, @HigherOrderLogic, @BennyDeeDevが実装に貢献

ポインタワープとスクロール

  • タイトルバーでのウィンドウ横ドラッグ時、 ポインタが画面端から反対側にワープ
  • Blenderのような 自然なスクロール操作 を実現

Screencasting（画面共有）機能の強化

  • xdg-desktop-portal-gnome経由PipeWire 推奨、 wlr-screencopy も対応
  • ウィンドウキャプチャ時のカーソル描画 に対応
    • PipeWireの メタデータカーソル 方式をサポート、OBS等でのカーソル非表示切替に対応
    • ウィンドウキャプチャ時は対象ウィンドウ上のみカーソル描画
  • @abmantisによるPipeWireの メモリ破損バグ発見・修正 と、その後のniri側実装
  • OBS等の消費側の実装状況 により一部最適化は未対応
  • PipeWireの仕様と実装の差異、今後の高品質なサンプル実装の必要性

この内容はniriの最新リリースノート・開発ブログの要点を日本語で簡潔にまとめたものです。各機能の詳細や設定例は公式ドキュメント・Wikiも参照してください。

Hackerたちの意見

Niri、めっちゃいいよね。5ヶ月前に使い始めたんだけど、Windowsから移行したのは最近の中で一番良い決断だったと思ってる。Niriの作者には感謝しかない！俺のdotfilesには、コマンドラインツールやテーマ切り替えの設定をするインストールスクリプトが含まれてるけど、今はArchベースのディストロでもNiriを完全にサポートしてるよ。新しいデスクトップ環境を探してる人には、すぐに始められるからおすすめ。メインのデスクトップと旅行用のノートパソコンの両方で使ってる。

└

同じく。Niriをウルトラワイドの曲面モニターと組み合わせると特に良いと思う。

└

Omarchyは、こういう感じでワークスペースごとにスクロールモードの切り替えを導入したんだ。Win/Cmd + Lを押すと、タイル表示からスクロールに切り替わるし、また戻せる。今はこれをずっと使ってるよ。

Niriでスクロールベースのウィンドウ管理を知って、すぐにハマった。最近、OmniWMにフルオンのNiriワークスペースエミュレーションモードが追加されて、Sequoiaとも互換性があって嬉しい。これが俺のメインのウィンドウマネージャーになったよ。

└

これだね。Niriのアプローチを発見した時、本当に楽しんだし、マックでも似たようなものを探してた。今まで試した中で一番の実装だと思うし、確かにいくつかのクセはあるけど、少なくとも自分の場合は日常的に使える完全なものだと感じてる（タブ付きのカラムが好き）。メンテナーと貢献者に感謝！

Macを使ってるなら、OmniWMをチェックしてみて。Niriレイアウトがあって、Hyprlandに近いレイアウトもあるよ。MacOSでの作業がずっと快適になった。少し前に使い始めた時に投稿したけど、本当に良かった。超おすすめ！

└

ごめん、でもあれは人生で見た中で最悪のデモ動画だよ。あの動画を見たら、誰もそのソフトウェアを試したいと思わないと思う。もし見たら、ユーザーでもアンインストールしたくなるかもね。

タイル型WMのワークフローに慣れすぎて、いろんな専用のフルスクリーンワークスペースを素早く切り替えたり、純粋にキーボードでウィンドウを管理するのが当たり前になってる。各ワークスペースには通常、1つのアプリかtmuxを使ったターミナルがあって、たまに2つのアプリを並べて使ったりする。似たようなワークフローからNiriに切り替えた人の意見を聞きたいな。メンタルモデルはどう変わった？

└

KDEから移行したんだけど、ほぼ君が言ってた通りだよ。ワークスペース1はフルスクリーンターミナル（zellij）、ワークスペース2はブラウザ、ワークスペース3は2つのチャットアプリを開いてるだけだった。切り替えのバインディングも設定してた。最初はNiriが違ってて軽量だったから使い始めたけど、今はワークフローを少し調整した。ほとんどの時間、個々のウィンドウは画面サイズのままで、同じように整理してる：1は開発、2はブラウザ（たまにメールリーダー）、3はチャットアプリ。コマンドをいくつか実行したり、長時間実行するものを時々確認するために新しいターミナルウィンドウを開くことが多くなった。KDEの時はウィンドウをバックグラウンドにしてたけど、今は「1」で横に並べてる。「Alt-Tab」で切り替えるのが今思うともっさりしてるなぁ…Super-hjklでウィンドウを切り替えるのと比べると。もちろん人それぞれだけど、俺のワークフローは「軽く」なったと思う。「ウィンドウが重なってる」んじゃなくて「隣に並んでる」感じ…軽やかさを感じる。

└

モニターごとに4つの固定ワークスペースを設定して、そうやって使ってるよ。

└

僕の考えでは、特定のアプリに専念したワークスペースはタイル型ウィンドウマネージャーには意味がないと思う。フローティングWMではそのワークフローは問題ないけど、タイル型WMの真価はウィンドウを実際にタイルするところにある。僕にとっては、ブラウザ、エディタ、ターミナルが一度に見えて、super+hjklやsuper+上下左右で空間的にナビゲートできるのが理想のトリニティ。だから、プロジェクトごとに1つのワークスペースを持つのが、タイル型WMの実際のワークフローとしてはずっと理にかなってる。Niriは新しいウィンドウを右に開けるようにして、現在のワークスペースのレイアウトを崩さないから、これを大幅に改善してくれるんだ。例えば、PDFを開く必要があるときとかね。トリニティを保ちながら、新しいウィンドウに簡単に切り替えられるのがいいんだ。

└

しばらくタイル型のウィンドウマネージャーを使ってたよ。君と似たような設定で（awesomeからqtile、短い間xmonad使って、最終的にはi3にしてWaylandにswayに切り替えたけど、hyprlandも少し試したことがある）。いつもぶつかるのは、3つ以上のウィンドウを横に並べるのがうまくいかないってこと。縦に分割するとウィンドウが小さくなっちゃうことも多いしね。一方で、何かを読んだり作業したりしている横に新しいウィンドウを開きたくなることがよくあった。例えば、ターミナルをいくつか開いていて、ipythonからプロットしたい時とか。それがいつも結構ストレスになって、要するに新しいウィンドウを開く前にいくつかのウィンドウをスタックレイアウトにまとめなきゃいけなかったり、横に並べたいウィンドウを新しいワークスペースに移動させたりしてた。これって、ウィンドウ管理を考えなきゃいけなくて、実際の作業から気が散っちゃうんだよね。niriを使うと、ただ新しいウィンドウを開けばいいし、必要なところに置けるし、他のウィンドウも左と右に残ってるから、そこに「スクロール」するだけで済む。今はワークフローがちょっと乱雑になったけど、それが逆に良いことだと思ってる。タイル型ウィンドウマネージャーは整理整頓が必要だけど、niriだとそんなの気にしなくていい。時々ウィンドウがすぐに見つからないこともあるけど、オーバービューを使えばいいし、ウィンドウ検索のrofiもあるからね。最初はswayのタグみたいに名前付きのワークスペースをいくつか持ってたけど、習慣で切り替えてたから。今はもう使ってないよ。

Hacker Newsで議論の続きを見る