Niri 26.04: スクロール型タイルリング Wayland コンポジター

 (github.com/niri-wm)
2 ポイント 投稿者 GN⁺ 3 일 전 | 1件のコメント | WhatsAppで共有
  • スクロール型タイルリング Wayland コンポジターとして、背景ぼかし、スクリーンキャスト、レンダリング、入力処理全般の改善が加わり、完成度がさらに高まった
  • 背景ぼかしがメインラインに取り込まれ、ext-background-effectをサポートするウィンドウや layer-shell 要素が、追加の niri 設定なしでぼかしを要求できるようになり、niri 側のルールでぼかしを強制適用することも可能になった
  • スクリーンキャストは、PipeWire と wlr-screencopy の両経路で、カーソル処理、dynamic cast の開始方式、IPC による問い合わせと強制終了、複数コピーやリソース解放の問題まで含めて改善された
  • レンダリング構造は iterator ベースから push ベースへ再構成され、レンダーリスト構築速度が主要マシンで 2〜3 倍、古い Eee PC では 8 倍高速化し、メモリ使用量も削減された
  • 旧型ハードウェアや入力環境にも手が入り、古い Intel システムでのスクリーンショット・スクリーンキャスト、IME と GTK 4 ポップアップの競合、高ポーリングレートのマウスやタブレットのマッピング、nested niri の DMA-BUF アクセラレーションなど、実利用できる範囲が広がった

主な変更点

  • GitHub 組織が個人アカウントから niri-wm に移され、関連プロジェクトもあわせて整理された
    • awesome-niri: 関連プロジェクト一覧
    • artwork: バッジと壁紙のコレクション
  • パッケージャー向けの変更も含まれる
    • 最低サポート Rust バージョンが 1.85 に引き上げられた
    • niri.service は、niri バイナリのパスに /usr/bin/ をもはやハードコードしない
    • dinit サービスファイルの構成が変更された: 3bfa4a7

背景ぼかし

  • 背景ぼかしがメインラインに入り、ウィンドウや layer-shell コンポーネントが ext-background-effect プロトコルでぼかしを要求できるようになった
  • アプリがまだ ext-background-effect をサポートしていなくても、window-rule と layer-rule により niri 側でぼかしを有効にできる
    • 詳細な設定と制約は Window Effects ドキュメントにまとまっている
    • niri で設定したぼかしには、適切な geometry-corner-radius が必要
    • 複雑な surface 形状には対応しない
  • xray blur と通常の blur の両方を提供し、デフォルトは xray blur
    • xray blur は壁紙を一度だけぼかして計算し、静的画像のように再利用するため、はるかに効率的
    • 壁紙が変わったときだけ再計算される
    • アニメーション壁紙では効率上の利点が小さくなる
    • 新しい layer matcher により、top や overlay のようなレイヤーにだけ通常の blur を適用するよう変更できる
  • ぼかし機能は、レンダリング構造の変更が必要になるほど実装難度が高かった
    • 通常の blur では、フレーム途中で既にレンダリングされたピクセルを再度読み出してぼかし、その後レンダリングを続行する
    • xray blur では、正しい背景切り出しのため、ウィンドウ位置をレンダリングコード全体に渡す必要があった
    • Overview で xray blur をサポートしつつ、overview を再レンダリングしない性質を維持する必要があった
    • スクリーンキャスト遮断ウィンドウ とも連携して動作する必要があった
  • ぼかしなしで xray だけを単独利用することもでき、blur の色帯を緩和するための noise や saturation 効果も個別に活用できる
  • 新しい popups ブロックにより、window rule または layer rule でポップアップメニューにも透明度や背景効果を適用できる
    • GTK 4 の has-arrow=true ポップアップのように、角丸矩形ではない場合は見た目が不自然になることがある
    • Web アプリや Electron は Wayland ポップアップを使わないため、niri では処理できない
    • ext-background-effect を直接実装したクライアントなら、より複雑な形状のぼかしも扱える

オプションの include

  • config include に オプションの include が追加された
    • include optional=true "optional-config.kdl" のように書くと、ファイルがなくても設定の読み込みは失敗しない
    • ファイルがなければ、設定を再読み込みするたびに警告ログを残すが、設定の読み込み自体は継続される
    • 後からファイルが作成されると、監視中だった変更が検知されて自動的に再読み込みされる
    • ファイルが存在していても構文エラーがあれば、引き続きパース失敗として扱われる
  • include パス中の ~ はホームディレクトリに展開される
    • ~/file.kdl は /home/user/file.kdl に展開される

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

  • ビューをスクロールするジェスチャー中、ポインターが画面の片端から反対側へワープするようになった
    • Blender に似た動作
    • モニター端の近くで開始しても、複数のウィンドウを自然にそのままスクロールし続けられる

スクリーンキャストの改善

  • niri のスクリーンキャストは、PipeWire 経由の xdg-desktop-portal-gnome と wlr-screencopy 経由の両方で改善

  • ウィンドウスクリーンキャストのカーソル処理

    • PipeWire でカーソルを映像フレーム内に直接描画する方式の代わりに、カーソルメタデータをサポート
      • 動画フレームにはカーソルを含めず、カーソルアイコンと座標を別バッファで送信
      • OBS やブラウザーなどのコンシューマー側がカーソルを自前で描画するようになる
    • モニターキャプチャとウィンドウキャプチャの両方で動作
    • ウィンドウキャプチャでは、そのウィンドウまたはそのポップアップを実際に指しているときだけカーソルが表示される
    • ドラッグアンドドロップアイコンも一緒に描画される
    • 実装過程で PipeWire の メモリー破損問題 も明らかになり、修正された
    • PipeWire の意図と libwebrtc のようなコンシューマー実装との不一致も確認された
    • テストした環境では正常に動作する
    • screenshot-window show-pointer=true でウィンドウスクリーンショットにもポインターを含められる

  • Dynamic cast target の開始方式変更

    • Dynamic cast target は、キーバインドでスクリーンキャスト対象を即座に切り替える機能
    • 以前は開始時に 1×1 の黒いピクセル映像ストリームとして開いていた
    • これからは 最初の実際の対象が選択されるまで映像ストリームの開始を遅延する
    • Microsoft Teams で短時間表示される 1×1 映像の問題を回避できる

  • Cast IPC

    • 現在進行中のスクリーンキャストを IPC で確認できるようになった
    • niri msg casts でアクティブなキャストを確認できる
    • event stream で cast events を購読できる
    • Cast オブジェクトは、種類、現在の対象、アクティブ状態を提供する
    • PipeWire スクリーンキャストは node ID を提供し、wlr-screencopy は クライアントプロセス ID を提供する
    • DankMaterialShell はすでにこの IPC でスクリーンキャストインジケーターを表示している
    • niri msg action stop-cast --session-id <ID> で PipeWire スクリーンキャストを強制終了できる

  • wlr-screencopy 関連の制限と修正

    • wlr-screencopy にはスクリーンキャストとスクリーンショットを堅牢に区別する方法がなく、一部ヒューリスティックが必要
    • xdg-desktop-portal-wlr は 1 つの wlr-screencopy manager オブジェクトを維持し続けるため、終了時点をすぐに把握しにくい
    • こうした問題は新しい ext-image-copy-capture プロトコルで解決されるが、niri にはまだ入っていない

  • その他のスクリーンキャスト修正

    • damage コピー時に、wlr-screencopy クライアントがカーソルを望まなくても常に含まれていた問題を修正
    • damage のある複数フレームコピーを同時に要求したときの動作を修正
    • クライアント終了時など、一部ケースで niri の wlr-screencopy データが解放されなかった問題を修正
    • 既定の PipeWire スクリーンキャストバッファ数を 16 から 8 に削減
    • pipewire-rs の use-after-free 問題を避けるため、構造体フィールドの順序を調整
    • dynamic cast 対象をウィンドウに切り替える際、1 フレームの間 z-order が誤っていたレンダリングを修正

アニメーションとウィンドウ動作

  • アニメーション同期がより正確になった
    • niri では個別のアニメーションを別々に設定できるが、互いに正確に一致する必要がある場合は同期して実行する
    • ウィンドウサイズ変更アニメーションは、それによって引き起こされる横方向のビュー移動アニメーションと同期される
    • fullscreen または maximize 解除時にビュー移動の同期が抜け、ウィンドウは即座に戻る一方で画面だけがゆっくりスクロールしていた問題を修正
  • 特定のドラッグ経路で 他のタイルウィンドウの横移動アニメーションがスキップされていた問題を修正
    • 最大化されたウィンドウをドラッグして解除し、もともとフローティングだったウィンドウなら再び floating に戻す動作と
    • モニター端付近でドラッグした際の左右 workspace スクロールロジックが重なって発生していた問題だった
    • 修正コミット: df3f3979e936ed6800b4fbd55843bb0fe2554f15
  • workspace の一番左の列を引き出してから再び戻したとき、元の位置ではなく右側に入っていた問題も修正
  • 設定エラー通知の表示時間は、アニメーション slowdown/speedup 設定の影響を受けないようになった

IME とポップアップ

  • GTK 4 のポップアップ入力欄と IME が一緒に動作しなかった長年の問題を回避的に解決
    • Fcitx5 などの IME を有効にした状態では、テキスト入力ポップアップを開けなかった
    • ポップアップがポインターとキーボード grab を取り、IME もキーボード grab を使うため衝突が発生していた
    • niri がポップアップ grab を手放すことで、ポップアップが即座に閉じることがあった
    • Smithay の構造を全面的に変えずに動作させるため、一部のチェックを緩和した
    • これにより IME ユーザーは Nautilus でのファイル名変更のような操作を行えるようになった

ドラッグアンドドロップと入力デバイス

  • ドラッグアンドドロップ中に Escape を押すと操作をキャンセルできるようになった
  • 入力デバイス全般にも複数の修正が加えられた
    • 高ポーリングレートのマウスと hide-after-inactive-ms またはアイドル監視デーモンを併用したとき、時間が経つほど遅くなっていた問題を修正
    • libwayland-server v1.23 以上では Wayland バッファサイズを増やし、応答のないウィンドウ上で高ポーリングレートのマウスを動かしたときにウィンドウがすぐクラッシュしないようにした
    • map-to-focused-output タブレットオプションが追加され、指定した単一出力ではなく現在フォーカスされている出力にマッピングできる
    • workspace 最上段のピクセルで、カーソルが最大化ウィンドウを常に正確に指せていなかった問題を修正
    • Alt-Tab が画面に表示される前にマウス入力へ反応していた問題を修正
    • trackball の on-button-down スクロールが overview でも動作する
    • カスタム .xkb keymap 読み込み後も Num Lock 状態を維持する
    • tmux 経由で別の TTY から起動したとき、入力デバイスをまったく使えなかった問題を修正
    • libinput plugins の読み込みを有効化

GPUプロファイリングとレンダリング最適化

  • Smithayとniriで使われている Tracy に GPUプロファイリング統合 が追加
    • GPUタイムスタンプクエリを送信し、完了した値を収集してTracyへ送る処理がSmithayに導入された: 作業PR
    • Smithay内部のGPU処理と、compositor自体のGPU処理の両方で区間表示が可能に
    • 単一フレーム内でDRMバッファレンダリングとPipeWireスクリーンキャストバッファレンダリングがどのように重なるかを追跡可能
    • マルチGPUシステムではGPUごとのトラックも確認可能
    • blur性能が予想より遅くないことを検証でき、GPUレンダリングのボトルネックによるdropped frameの診断もしやすくなった
  • レンダーリスト構成方式 がiteratorベースからpushベースへ再構成
    • 従来は -> impl Iterator<Item = ...> 形式でレンダー要素を組み合わせていた
    • 条件分岐、lifetime、&self の借用、&mut Renderer との衝突、中間 Vec 割り当て、crate境界の問題など、さまざまな複雑さがあった
    • 新しい構造では、レンダー関数が push: &mut dyn FnMut(Element) を受け取り、要素を押し込む方式になった
    • 中間関数は上位の push をラップしたクロージャで既存ロジックを維持できる
    • 一時 Vec がなくなり、borrowing問題も解消
    • niriではiteratorの早期終了の利点は実際には必要なかった
  • このリファクタリングにより レンダーリスト構成速度 が大幅に高速化
    • 主要マシンでは2～3倍高速化
    • 古いEee PCでは8倍高速化
    • レンダーリスト構成は実際のGPUレンダリング時間そのものではないが、画面を再描画しなくても頻繁に実行されるため改善効果が大きい
    • メモリ使用量も減少し、新しい経路での割り当てはほとんどが出力ベクタの拡張だけになった
    • 詳しい動機とdiffは PR で確認できる

旧型ハードウェア対応

  • 古いIntelノートPCでスクリーンショットが失敗していた原因が Smithayの誤ったOpenGL enum値 だと判明し、修正された: 原因分析PR
  • niriシェーダーも小幅に最適化され、非常に古いASUS Eee PCの制約の大きいGPUでも
    • ウィンドウのリサイズアニメーション
    • compositorの角丸
    • が動作可能になった

その他の改善

  • 一部システムで特定アプリ終了後に発生していた VRAMリーク を修正
  • ext-foreign-toplevel-list プロトコルが追加され、QuickshellなどでWaylandウィンドウオブジェクトとniri IPCウィンドウIDを結び付けやすくなった
  • 設定で重複bindエラーが出た場合、同じbindの 最初の定義位置 もあわせて表示
  • Mod+LMBでウィンドウをドラッグするときに grabbing cursor を表示
  • niri msg action load-config-file に --path 引数が追加され、実行時に別の設定ファイルへ切り替え可能に
  • nested niriに DMA-BUF対応 が入り、Mesaの wl_drm 廃止後もハードウェアアクセラレーションが再び動作
  • モニター端付近のlayer-shellポップアップにniriが入れていたpaddingを削除
  • デフォルト設定 の変更も含む
    • Mod+M: maximize-window-to-edges
    • Mod+Shift+R: switch-preset-column-width-back
  • force-disable-connectors-on-resume デバッグフラグが追加され、TTY切り替えやスリープ復帰時に画面を強制的にblank処理できる
  • windowed fullscreenでウィンドウの角が正しく 直角処理 されるよう修正
  • overviewが開いている間、画面が継続的に再描画されていた問題を修正
  • インタラクティブドラッグ中の relative-to=workspace-view gradient border レンダリングを小幅に補正
  • Important Hotkeysダイアログのdiaeresisショートカットのレンダリングを調整
  • niri msg action の expel-window-from-column 説明を実際の動作に合わせて 下側のウィンドウを追い出す方式 に修正
  • 最近削除されたoutputをクライアントが使おうとした際に起こり得た複数のpanicを修正
  • clip-to-geometry が y_invert バッファをアタッチするクライアントと併用されたとき、レンダリングが壊れていた問題を修正
  • OpenBSDビルドを修正
  • nested niriが自分のウィンドウ app-id を設定するよう変更
  • 新しいGPUが接続されると ignore-drm-device デバッグ設定を再評価し、/dev/dri/by-path/ シンボリックリンクも活用できるようになった

Smithayアップデート反映

  • Smithayアップデートにより複数の基盤改善も加わった
    • ARM Macのような一部デバイスで 自動GPU選択 が改善
    • AsahiとPinephoneは手動の render-drm-device 設定なしでそのまま動作可能に
    • wl_shimeji のような一部layer-shellクライアントの動作が改善
    • モニターEDIDの読み込みが遅いドックのサポートが改善
    • 古いIntelシステムでスクリーンショットとスクリーンキャストが動作
    • スリープ中にUSB-Cドックを外した際、古いoutputが残る問題を修正
    • 一部クライアントで zxdg_exporter_v2 panicを修正
    • クリップボードプロトコルを明示的に破棄しないクライアントのメモリリークを修正
    • GTK 4.23開発リリースで発生し始めたtext-input content hint、purpose関連のpanicを修正
    • drag-and-drop、IME text input、multi-GPUと全体的な性能も改善された

関連記事

1件のコメント

 
GN⁺ 3 일 전
Hacker Newsのコメント

  • Niriがあまりにも良くて、5か月ほど前に乗り換えて以来、ここ数年でWindowsを離れたことの中でも一番良い決断だったと感じている
    作者には本当に強く感謝している
    自分の dotfiles にはもともと CLI ツールの設定やテーマ切り替えなどのためのインストールスクリプトが入っていたが、今では Arch 系でも Niri を完全にサポートしている
    新しいデスクトップ環境をすぐ試したいなら https://github.com/nickjj/dotfiles がかなり手早い出発点になる
    メインのデスクトップと旅行用ノートPCの両方で使っている

    • 自分も同じで、ウルトラワイドの曲面モニターと Niri の組み合わせは特に相性がいい
    • Nirimodもぜひ見てほしい
      非公式だが本当に素晴らしい
    • Omarchy はこうしたワークスペースごとの scrollable モード切り替えを入れている
      Win/Cmd + L を押すと tiling と scrolling を切り替えられて、今ではこれを本当によく使っている

  • Niri のおかげでスクロールベースのウィンドウ管理を初めて体験したが、すぐにしっくりきた
    最近 Mac 向けの OmniWM にワークスペース単位で完全な Niri エミュレーションモードが入って、幸い Sequoia とも互換性があるので、そのままメインのウィンドウマネージャーになった
    [1] https://github.com/BarutSRB/OmniWM

    • Paneruは macOS で Niri を再現することを目的に最初から作られた新しいツールだ
    • 自分も似た感じだ
      Niri のやり方を初めて知ったとき本当に気に入って、Mac でも似たものをずっと探していた
      これまで使った中で最高の実装で、細かな quirks は確かにあるが、少なくとも自分にとっては daily driver として十分使える
      特にtabbed columnsが本当にいい
      メンテナーとコントリビューターには拍手を送りたい

  • Mac を使うなら OmniWM を勧める
    Niri スタイルのレイアウトだけでなく Hyprland により近いレイアウトもあり、そのおかげで macOS での作業がずっと快適になった
    https://github.com/BarutSRB/OmniWM
    以前に使い始めたばかりの頃にも投稿したことがあるが、その後も使い続けてみて本当に良かったので強く勧められる

    • 申し訳ないが、デモ動画は自分の人生で見た中でも最悪のデモ動画レベルだ
      あれを見てこのソフトウェアを使ってみたくなる人はいないと思うし、すでに使っている人ですら削除したくなるほどだ

  • GNOME 向けの PaperWM extension を使っているが、たぶん Niri もここから着想を得たのだと思う
    確かに面白い作業スタイルではあるが、1つのワークスペースにウィンドウが3つを超えると少し煩わしく感じるので、完全に惚れ込むには至っていない
    それでもちゃんと使ってみているし、GNOME extension なので過剰な設定なしに他の GNOME DE をそのまま使えるのは良い

    • しばらく Niri に移行したかったが、周辺設定を整えるのに毎回何日もかかっていた
      top bar、idle timeout、通知のようなものまで全部面倒を見る必要があったからだ
      ところが最近 Wayland 向けの desktop shell があることを知り、GNOME のような環境で期待するものの大半を大きな手間なく提供してくれる
      設定ダイアログ、アプリトレイ、リソース監視、top bar まで全部含まれている
      今は dank material shell を使っているが、desktop shell と compositor を好き勝手に組み合わせられるのは本当に面白い
    • 自分も同じで、PaperWM が侵襲的でない GNOME extensionである点が気に入っている
      ワークフロー全体が良くなっただけでなく、そのおかげで desktop grid のような他の extension も2〜3個削除できた

  • 複数の専用 fullscreen ワークスペースを素早く行き来し、キーボードだけでウィンドウ管理する tiling WM の流れに完全に慣れている
    たいてい各ワークスペースにはアプリ1つ、あるいは tmux を開いたターミナル1つを置き、たまにだけアプリ2つを並べる
    似たような流れから Niri に移った人たちが、メンタルモデルをどう変えたのか本当に気になる

    • KDE、GNOME、Niri のどれでもずっとアクティビティ/プロジェクトごとのワークスペースを使ってきた
      Steam とゲーム Wiki があるワークスペース、Emacs と文書ブラウザがあるワークスペース、Godot とゲーム開発アプリがあるワークスペース、といった具合だ
      Niri の良いところは、ウィンドウが多すぎると感じて何かを閉じなければならないという圧力がほとんどないことだ
      分けて整理するのがかなり簡単だ
      アプリごとのワークスペースをなぜ使うのかはあまり分からない
      Firefox 1つの中に仕事用と趣味用のタブが混ざるのも嫌いだ
    • かなり長くtiling ユーザーで、構成も似ていた
      awesome、qtile、少しだけ xmonad、その次に i3、Wayland に移ってから sway、さらに hyprland も少し使った
      いつもぶつかっていたのは、ウィンドウが3つを超えると横並びはうまくいかず、縦分割は小さくなりすぎるという点だった
      一方で、読んでいるものの横に新しいウィンドウを開いたり、ターミナルの横に ipython のプロットを出したくなる場面はよくあった
      そのたびに stacked layout にまとめたり新しいワークスペースへ移したりする必要があり、かなり摩擦があって、ウィンドウ管理のせいで作業の流れが何度も途切れていた
      Niri では新しいウィンドウをそのまま開けば必要な場所に現れ、他のウィンドウは左右にそのまま残っていて、スクロールすれば行ける
      今ではワークフローは以前より少し散らかっているが、むしろその方がいい
      従来の tiling WM は整理を要求し、それをしやすくもしてくれるが、Niri では無理に整理する必要がない
      たまにウィンドウをすぐ見つけられないときは overview を使い、自分は rofi でウィンドウ検索も追加している
      最初は sway 時代の癖で名前付きワークスペースを使い続けていたが、今ではもう使っていない
    • KDE からほぼ同じ流れで移ってきた
      ワークスペース 1 は zellij を開いた fullscreen ターミナル、2 はブラウザ、3 はチャットアプリ2つくらいで、ショートカットで行き来していた
      最初は Plasma より軽くて違うという理由で Niri を使っていたが、今ではワークフローも少し変わった
      大半のウィンドウは今でも画面サイズいっぱいで使い、1 は開発、2 はブラウザと時々メールリーダー、3 はチャットアプリというように似た形で整理している
      ただ、短いコマンドを打ったり長時間走る作業を置いておいたりするときには、新しいターミナルウィンドウをずっと頻繁に開くようになった
      KDE ではこうしたウィンドウは後ろで重なっていたが、今では 1 の中で横に並ぶ
      振り返ると、Alt-Tab で行き来していたやり方は今ではかなり窮屈に感じられ、Super-hjkl で移る方がずっと軽い
      もちろん人それぞれだが、ウィンドウが重なる代わりに隣に置かれる感覚がワークフローをより軽くしてくれる
    • それは実際にはtilingというより、fullscreen とワークスペースの組み合わせに近く見える
      i3 や sway のような手動タイル型 WM と大きなモニターを使えば、画面を複数の作業領域に分けて、それぞれの領域に役割別のアプリを複数置き、ワークスペース数を減らすことができる
      scrolling は似ているが別の流れで、特に小さな画面で柔軟性が重要なときに合っている
    • アプリ1つにつき1ワークスペースは tiling WM ではあまり意味がないと思う
      その流れは floating WM の方に向いている
      tiling WM の本当の利点はウィンドウを実際にタイル状に並べることにあり、自分にとってはブラウザ・エディタ・ターミナルが同時に見えるholy trinityが核心だ
      そして super+hjkl や方向キーで空間的に移動できる必要がある
      だからプロジェクトごとのワークスペースの方がずっと自然で、tiling WM らしい流れだと感じる
      Niri は新しいウィンドウを右側に開いて現在のレイアウトを壊さないので、これをずっと上手くやってくれる
      例えば PDF を開いても既存の構成を保ったまま新しいウィンドウへ簡単に移れる

  • 関連リンク
    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)

  • NNN (Niri-Nix-Noctalia) dotsを試したければ、自分の flake を持っていっていい
    https://github.com/MostlyKIGuess/nix-flake-public

    • 数年間 window manager を使ってきたが、WM の外側の設定まで自分でいじらなければならない壁のせいで、結局完成されたデスクトップ環境に戻った
      ダークモードのようなことですら手間がかかったが、Noctalia は自分が求めていたまさにその方向に見える
      紹介してくれてありがとう

  • mangowm の wl-only ブランチ（wlroots 0.20 ベース）を使っている
    リソース消費がずっと少なく、レイアウトも多く、問題も少ない
    Niri の方が視覚効果は良く見えるが、一度試す価値は十分ある
    HDR が必要ならまだ待つ必要がある
    https://github.com/mangowm/mango

    • どんな問題が少ないという意味なのか気になる
      自分のところでは Niri は本当に rock solid だった

  • ロシアの天才が1億ドル分の Claude トークンより良いものを作ってしまった、という話に見える
    完全な集団狂気なんてことは決してないから、みんな SPY を買えという空気だ

    • 本当に天才なんだと思う
      リリースノートを見ると、それ自体が美しいと言えるほどだ

  • 去年の終わりに i3 を10年以上使った後で Niri に移った
    モニターサイズに縛られない横スクロールと、設定したショートカット数に縛られないワークスペース数が本当に解放感をくれる
    グラフィック面の完成度も高い
    ただ、まだ残る不満は X 互換レイヤーの xwayland-satellite が X アプリと Wayland アプリ間の drag and drop をまだサポートしていないことだ
    [1]: https://davidyat.es/2026/01/28/niri/
    [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

    • 自分も似た状況だ
      以前はいつも同じワークスペースに同じものを置く癖があったので簡単に覚えられたが、今では配置があちこちに散らばるようになった
      それに scratch がかなり切実に恋しい
      もう少し真面目に設定をいじれば解決できそうではあるが、まだそこまで時間をかけていない