▲

Niri 26.04: 스크롤형 타일링 Wayland 컴포지터

 (github.com/niri-wm)
1P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • 스크롤형 타일링 Wayland compositor에 배경 흐림, 스크린캐스트, 렌더링, 입력 처리 전반의 개선이 더해지며 완성도가 커짐
  • 배경 흐림이 메인라인에 포함되어 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으로 옮겨졌고, 관련 프로젝트도 함께 정리됨
  • 패키저 관련 변경도 포함됨
    • 최소 지원 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 팝업처럼 둥근 직사각형이 아닌 경우 모양이 어색할 수 있음
    • 웹앱이나 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은 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 대상을 창으로 바꿀 때 한 프레임 동안 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 또는 idle 모니터링 데몬을 함께 쓸 때 시간이 갈수록 느려지던 문제를 고침
    • 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 노트북에서 스크린샷이 실패하던 문제의 원인이 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와 성능 전반도 개선됨

함께 보면 좋은 글 β

▲
GN⁺ 10시간전  [-]
Hacker News 의견들

  • Niri가 너무 좋아서 5개월 전쯤 갈아탄 뒤로, 최근 몇 년 사이 Windows를 떠난 것 중 가장 잘한 결정처럼 느껴짐
    작성자에게 정말 크게 고마움을 느끼고 있음
    내 dotfiles는 원래 CLI 도구 설정, 테마 전환 등을 위한 설치 스크립트를 포함했는데, 이제 Arch 계열에서는 Niri도 완전히 지원함
    새 데스크톱 환경을 빨리 써보고 싶다면 https://github.com/nickjj/dotfiles가 꽤 바로 출발하기 좋음
    메인 데스크톱과 여행용 노트북 둘 다에서 쓰는 중임

    • 나도 같고, ultrawide 커브드 모니터와 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도 여기서 영감을 받은 것 같음
    확실히 흥미로운 작업 방식이지만, 한 워크스페이스에 창이 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 두세 개도 지울 수 있었음

  • 여러 개의 전용 fullscreen 워크스페이스를 빠르게 넘나들고, 키보드만으로 창 관리하는 tiling WM 흐름에 완전히 익숙해졌음
    보통 워크스페이스마다 앱 하나 또는 tmux가 열린 터미널 하나를 두고, 가끔만 앱 둘을 나란히 놓음
    비슷한 흐름에서 Niri로 넘어간 사람들은 멘탈 모델이 어떻게 바뀌는지 정말 궁금함

    • KDE, GNOME, Niri 모두에서 늘 활동/프로젝트별 워크스페이스를 써왔음
      Steam과 게임 위키가 있는 워크스페이스, Emacs와 문서 브라우저가 있는 워크스페이스, Godot와 게임개발 앱이 있는 워크스페이스 식임
      Niri의 좋은 점은 창이 너무 많아졌다고 느껴서 뭔가를 닫아야겠다는 압박이 거의 없다는 데 있음
      분리해서 정리하기가 꽤 쉬움
      앱별 워크스페이스는 왜 쓰는지 잘 모르겠음
      Firefox 하나에 일과 취미 탭이 다 섞여 있는 것도 싫어함
    • 꽤 오래 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은 채팅 앱 두 개 정도였고 단축키로 오갔음
      처음엔 Plasma보다 가볍고 다르다는 이유로 Niri를 썼는데, 지금은 워크플로우도 조금 바뀌었음
      대부분의 창은 여전히 화면 크기만 하게 쓰고, 1은 개발, 2는 브라우저와 가끔 메일 리더, 3은 채팅 앱처럼 비슷하게 정리함
      다만 짧은 명령을 치거나 오래 도는 작업을 띄워둘 때 새 터미널 창을 훨씬 자주 엶
      KDE에서는 이런 창들이 뒤에 겹쳐 있었는데, 지금은 1번 안에서 나란히 놓임
      돌이켜보면 Alt-Tab으로 오가던 방식이 이제는 꽤 답답하게 느껴지고, Super-hjkl로 넘기는 편이 훨씬 가벼움
      물론 사람마다 다르겠지만, 창이 서로 겹치는 대신 옆에 놓이는 느낌이 워크플로우를 더 가볍게 만들어줌
    • 그건 사실 tiling이라기보다 fullscreen과 워크스페이스 조합에 더 가까워 보임
      i3나 sway 같은 수동 타일링 WM과 큰 모니터를 쓰면, 화면을 여러 작업 구역으로 나눠서 각 구역에 역할별 앱 여러 개를 두고 워크스페이스 수를 줄일 수 있음
      scrolling은 비슷하지만 다른 흐름이고, 특히 작은 화면에서 유연성이 중요할 때 잘 맞음
    • 앱 하나당 워크스페이스는 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가 꽤 절실하게 그리움
      조금 더 부지런히 설정을 손보면 해결될 것 같긴 한데, 아직 거기까지 시간을 쓰진 않았음
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.