Niri 26.04: Trình compositor Wayland xếp ô cuộn

 (github.com/niri-wm)
1 điểm bởi GN⁺ 11 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trình compositor Wayland xếp ô cuộn được hoàn thiện hơn nhờ các cải tiến trên diện rộng về làm mờ nền, screencast, dựng hình và xử lý đầu vào
  • Làm mờ nền đã được đưa vào nhánh chính, cho phép các cửa sổ và thành phần layer-shell hỗ trợ ext-background-effect yêu cầu làm mờ mà không cần cấu hình niri riêng, đồng thời cũng có thể ép áp dụng làm mờ bằng các quy tắc phía niri
  • Screencast được tinh chỉnh đồng thời ở cả PipeWire và đường dẫn wlr-screencopy, bao gồm xử lý con trỏ, cách bắt đầu dynamic cast, truy vấn và buộc dừng qua IPC, cũng như các vấn đề sao chép nhiều lần và giải phóng tài nguyên
  • Cấu trúc dựng hình được tái tổ chức từ kiểu dựa trên iterator sang kiểu push, giúp tốc độ xây dựng danh sách render nhanh hơn 2–3 lần trên các máy chính và nhanh hơn 8 lần trên Eee PC cũ, đồng thời giảm mức dùng bộ nhớ
  • Phần cứng cũ và môi trường nhập liệu cũng được cải thiện, mở rộng phạm vi sử dụng thực tế với screenshot/screencast trên hệ thống Intel đời cũ, xung đột giữa IME và popup GTK 4, chuột tần số quét cao và ánh xạ tablet, cùng tăng tốc DMA-BUF cho niri lồng nhau

Các thay đổi chính

  • Tổ chức GitHub đã được chuyển từ tài khoản cá nhân sang niri-wm, đồng thời các dự án liên quan cũng được sắp xếp lại
    • awesome-niri: danh sách các dự án liên quan
    • artwork: bộ sưu tập huy hiệu và hình nền
  • Cũng có các thay đổi liên quan đến việc đóng gói
    • Phiên bản Rust tối thiểu được hỗ trợ đã tăng lên 1.85
    • niri.service không còn hardcode đường dẫn nhị phân niri là /usr/bin/
    • Cấu trúc tệp dịch vụ dinit đã thay đổi: 3bfa4a7

Làm mờ nền

  • Làm mờ nền đã vào nhánh chính, và các cửa sổ cùng thành phần layer-shell có thể yêu cầu làm mờ qua giao thức ext-background-effect
  • Ngay cả khi ứng dụng chưa hỗ trợ ext-background-effect, vẫn có thể bật làm mờ từ phía niri bằng window-rule và layer-rule
    • Thiết lập chi tiết và các giới hạn được tổng hợp trong tài liệu Window Effects
    • Làm mờ được cấu hình từ niri cần geometry-corner-radius chính xác
    • Không hoạt động với các dạng surface phức tạp
  • Cung cấp đồng thời xray blur và blur thông thường, với mặc định là xray blur
    • Xray blur chỉ tính toán làm mờ hình nền một lần rồi tái sử dụng như ảnh tĩnh nên hiệu quả hơn nhiều
    • Chỉ được tính lại khi hình nền thay đổi
    • Với hình nền động, lợi thế hiệu năng sẽ giảm đi
    • Có thể dùng matcher layer mới để chỉ áp dụng blur thông thường cho các layer như top hoặc overlay
  • Tính năng làm mờ có độ khó triển khai cao đến mức cần thay đổi cấu trúc dựng hình
    • Blur thông thường sẽ đọc lại các pixel đã được render ở giữa khung hình, làm mờ chúng rồi tiếp tục render
    • Xray blur yêu cầu truyền vị trí cửa sổ xuyên suốt mã render để cắt nền chính xác
    • Cần giữ nguyên đặc tính của Overview là không render lại overview trong khi vẫn hỗ trợ xray blur
    • Đồng thời cũng phải hoạt động với các cửa sổ bị chặn khỏi screencast
  • Có thể dùng chỉ xray mà không cần blur, và cũng có thể dùng riêng hiệu ứng noise cùng saturation để giảm hiện tượng dải màu của blur
  • Khối popups mới cho phép áp dụng độ trong suốt và hiệu ứng nền cho cả menu popup trong window rule hoặc layer rule
    • Với các trường hợp không phải hình chữ nhật bo góc như popup has-arrow=true của GTK 4, hình dạng có thể trông không tự nhiên
    • Web app và Electron không dùng popup Wayland nên niri không thể xử lý
    • Các client tự triển khai ext-background-effect có thể xử lý cả những kiểu làm mờ với hình dạng phức tạp hơn

Include tùy chọn

  • config include đã được bổ sung include tùy chọn
    • Dùng như include optional=true "optional-config.kdl", khi đó thiếu tệp cũng không làm thất bại việc nạp cấu hình
    • Nếu tệp không tồn tại, mỗi lần reload cấu hình vẫn sẽ ghi log cảnh báo nhưng cấu hình tiếp tục được nạp
    • Nếu tệp được tạo sau đó, thay đổi đang được theo dõi sẽ được phát hiện và tự động nạp lại
    • Nếu tệp có tồn tại nhưng lỗi cú pháp, vẫn sẽ bị xử lý là lỗi parse
  • Ký tự ~ trong đường dẫn include sẽ được mở rộng thành thư mục home
    • ~/file.kdl sẽ được mở rộng thành /home/user/file.kdl

Pointer warping và cuộn

  • Trong cử chỉ cuộn chế độ xem, con trỏ sẽ được warp từ một mép màn hình sang mép đối diện
    • Cách hoạt động này tương tự Blender
    • Nhờ đó, ngay cả khi bắt đầu gần mép màn hình, vẫn có thể tiếp tục cuộn qua nhiều cửa sổ một cách tự nhiên

Cải thiện screencast

  • Screencast của niri đã được cải thiện ở cả hai cách: xdg-desktop-portal-gnome thông qua PipeWire hoặc thông qua wlr-screencopy

  • Xử lý con trỏ trong screencast cửa sổ

    • PipeWire nay hỗ trợ metadata con trỏ thay vì vẽ trực tiếp con trỏ vào trong khung hình video
      • Khung hình video sẽ không chứa con trỏ; biểu tượng con trỏ và tọa độ được gửi trong bộ đệm riêng
      • Bên tiêu thụ như OBS hoặc trình duyệt sẽ tự vẽ con trỏ
    • Hoạt động với cả chụp màn hình theo màn hình lẫn theo cửa sổ
    • Với chụp cửa sổ, con trỏ chỉ hiện khi thực sự đang trỏ vào cửa sổ đó hoặc popup của nó
    • Biểu tượng kéo thả cũng được vẽ cùng
    • Trong quá trình triển khai, một vấn đề hỏng bộ nhớ của PipeWire cũng được phát hiện và sửa
    • Cũng xác nhận có sự không khớp giữa ý đồ của PipeWire và cách triển khai ở phía consumer như libwebrtc
    • Trong môi trường đã thử nghiệm, tính năng hoạt động bình thường
    • Có thể đưa con trỏ vào ảnh chụp cửa sổ bằng screenshot-window show-pointer=true

  • Thay đổi cách khởi động Dynamic cast target

    • Dynamic cast target là tính năng đổi ngay mục tiêu screencast bằng keybind
    • Trước đây khi khởi động, nó mở bằng luồng video pixel đen 1×1
    • Giờ đây sẽ trì hoãn việc bắt đầu luồng video cho đến khi mục tiêu thực đầu tiên được chọn
    • Điều này giúp tránh hiện tượng video 1×1 ngắn xuất hiện trong Microsoft Teams

  • Cast IPC

    • Giờ có thể kiểm tra screencast đang chạy qua IPC
    • Có thể xem cast đang hoạt động bằng niri msg casts
    • Có thể đăng ký cast events trong event stream
    • Đối tượng Cast cung cấp loại, mục tiêu hiện tại và trạng thái hoạt động
    • Screencast PipeWire cung cấp node ID, còn wlr-screencopy cung cấp client process ID
    • DankMaterialShell đã dùng IPC này để hiển thị chỉ báo screencast
    • Có thể buộc dừng screencast PipeWire bằng niri msg action stop-cast --session-id <ID>

  • Giới hạn và chỉnh sửa liên quan đến wlr-screencopy

    • wlr-screencopy không có cách phân biệt chắc chắn giữa screencast và screenshot, nên cần một số heuristic
    • xdg-desktop-portal-wlr giữ nguyên một đối tượng wlr-screencopy manager, nên khó biết chính xác thời điểm kết thúc
    • Các vấn đề này được giải quyết trong giao thức mới ext-image-copy-capture, nhưng niri vẫn chưa tích hợp

  • Các chỉnh sửa screencast khác

    • Sửa lỗi khi sao chép damage thì client wlr-screencopy luôn bị kèm cả con trỏ dù không mong muốn
    • Sửa hành vi khi đồng thời yêu cầu sao chép nhiều khung hình có damage
    • Sửa lỗi trong một số trường hợp như khi client đã thoát, dữ liệu wlr-screencopy của niri không được giải phóng
    • Giảm số lượng buffer screencast PipeWire mặc định từ 16 xuống 8
    • Điều chỉnh thứ tự trường của struct để tránh lỗi use-after-free trong pipewire-rs
    • Sửa lỗi render khiến z-order sai trong một khung hình khi đổi mục tiêu dynamic cast sang cửa sổ

Hoạt ảnh và hành vi cửa sổ

  • Đồng bộ hoạt ảnh nay chính xác hơn
    • niri có thể cấu hình riêng từng hoạt ảnh, nhưng khi cần khớp chính xác thì chúng sẽ chạy đồng bộ
    • Hoạt ảnh đổi kích thước cửa sổ được đồng bộ với hoạt ảnh dịch chuyển khung nhìn theo chiều ngang mà nó gây ra
    • Đã sửa lỗi thiếu đồng bộ dịch chuyển khung nhìn khi thoát fullscreen hoặc maximize, khiến cửa sổ quay về ngay còn màn hình lại cuộn chậm
  • Đã sửa lỗi hoạt ảnh di chuyển ngang của các cửa sổ xếp ô khác bị bỏ qua trên một số đường kéo nhất định
    • Vấn đề xảy ra khi kéo để thoát maximize, rồi nếu đó vốn là cửa sổ nổi thì đưa nó trở lại floating,
    • đồng thời logic cuộn workspace trái/phải khi kéo gần mép màn hình bị chồng lấn
    • Commit sửa lỗi: df3f3979e936ed6800b4fbd55843bb0fe2554f15
  • Cũng sửa lỗi khi kéo cột ngoài cùng bên trái của workspace ra rồi thả lại thì nó chèn sang bên phải thay vì quay về vị trí cũ
  • Thời gian hiển thị thông báo lỗi cấu hình giờ không còn bị ảnh hưởng bởi thiết lập slowdown/speedup của hoạt ảnh

IME và popup

  • Đã khắc phục theo hướng workaround một lỗi lâu năm khiến ô nhập trong popup GTK 4 và IME không hoạt động cùng nhau
    • Khi bật IME như Fcitx5, trước đây không thể mở popup nhập văn bản
    • Popup giữ pointer và keyboard grab, còn IME cũng dùng keyboard grab nên phát sinh xung đột
    • niri từng bỏ popup grab khiến popup thường đóng ngay lập tức
    • Đã nới lỏng một số kiểm tra để nó hoạt động mà không cần thay đổi hoàn toàn cấu trúc Smithay
    • Giờ người dùng IME có thể làm các việc như đổi tên tệp trong Nautilus

Kéo thả và thiết bị nhập

  • Giờ có thể nhấn Escape để hủy thao tác trong lúc kéo thả
  • Nhiều chỉnh sửa cũng được áp dụng cho thiết bị nhập nói chung
    • Sửa lỗi hệ thống chậm dần theo thời gian khi dùng chuột polling rate cao cùng hide-after-inactive-ms hoặc daemon theo dõi idle
    • Trên libwayland-server v1.23 trở lên, tăng kích thước buffer Wayland để cửa sổ không bị crash quá nhanh khi di chuyển chuột polling rate cao trên một cửa sổ không phản hồi
    • Bổ sung tùy chọn tablet map-to-focused-output, cho phép ánh xạ tới đầu ra đang được focus thay vì một đầu ra đơn được chỉ định
    • Sửa lỗi con trỏ không phải lúc nào cũng trỏ chính xác vào cửa sổ maximize ở pixel trên cùng của workspace
    • Sửa lỗi Alt-Tab phản ứng với input chuột trước khi hiển thị trên màn hình
    • Cuộn on-button-down của trackball nay hoạt động cả trong overview
    • Giữ nguyên trạng thái Num Lock ngay cả sau khi tải custom .xkb keymap
    • Sửa lỗi hoàn toàn không dùng được thiết bị nhập khi khởi động từ TTY khác thông qua tmux
    • Bật nạp libinput plugins

Profiling GPU và tối ưu hóa kết xuất

  • Đã bổ sung tích hợp profiling GPU cho Tracy được dùng trong Smithay và niri
    • Smithay đã thêm phần gửi truy vấn dấu thời gian GPU, thu thập các giá trị đã hoàn tất và chuyển chúng tới Tracy: PR triển khai
    • Giờ đây có thể đánh dấu phạm vi cho cả các tác vụ GPU nội bộ của Smithay lẫn các tác vụ GPU của chính compositor
    • Có thể theo dõi cách kết xuất bộ đệm DRM và kết xuất bộ đệm screencast PipeWire chồng lấp nhau trong một khung hình
    • Trên hệ thống đa GPU, cũng có thể xem track theo từng GPU
    • Có thể xác minh rằng hiệu năng blur không chậm như dự đoán, đồng thời cũng dễ chẩn đoán dropped frame do nghẽn kết xuất GPU hơn
  • Cách xây dựng danh sách render đã được tái cấu trúc từ kiểu dựa trên iterator sang kiểu dựa trên push
    • Trước đây, các phần tử render được kết hợp dưới dạng -> impl Iterator<Item = ...>
    • Có nhiều độ phức tạp như phân nhánh điều kiện, lifetime, mượn &self, xung đột với &mut Renderer, cấp phát Vec trung gian và vấn đề ở ranh giới crate
    • Cấu trúc mới để hàm render nhận push: &mut dyn FnMut(Element) rồi đẩy các phần tử vào
    • Các hàm trung gian có thể giữ nguyên logic cũ bằng closure bọc quanh push ở tầng trên
    • Vec tạm thời biến mất và các vấn đề borrowing cũng được loại bỏ
    • Trong niri, lợi thế dừng sớm của iterator thực tế không cần thiết
  • Nhờ lần refactor này, tốc độ xây dựng danh sách render đã tăng đáng kể
    • Trên máy chính, nhanh hơn 2–3 lần
    • Trên chiếc Eee PC cũ, nhanh hơn 8 lần
    • Việc xây dựng danh sách render không phải chính thời gian kết xuất GPU thực tế, nhưng nó vẫn chạy thường xuyên ngay cả khi màn hình không cần vẽ lại nên tác động cải thiện là rất lớn
    • Mức dùng bộ nhớ cũng giảm, và phần cấp phát của đường đi mới giờ chủ yếu chỉ còn ở việc mở rộng vector đầu ra
    • Có thể xem thêm động cơ và diff chi tiết trong PR

Hỗ trợ phần cứng cũ

  • Nguyên nhân khiến chụp màn hình thất bại trên các laptop Intel cũ được xác định là do giá trị OpenGL enum sai trong Smithay và đã được sửa: PR phân tích nguyên nhân
  • Shader của niri cũng được tối ưu nhẹ để ngay cả trên GPU hạn chế của những máy rất cũ như ASUS Eee PC thì
    • hoạt ảnh đổi kích thước cửa sổ
    • góc bo tròn của compositor
    • đều có thể hoạt động

Các cải tiến khác

  • Đã sửa lỗi rò rỉ VRAM xảy ra trên một số hệ thống sau khi đóng một số ứng dụng nhất định
  • Đã thêm giao thức ext-foreign-toplevel-list, giúp dễ liên kết đối tượng cửa sổ Wayland với ID cửa sổ niri IPC trong Quickshell và các môi trường tương tự
  • Khi có lỗi bind trùng lặp trong cấu hình, giờ cũng hiển thị vị trí định nghĩa đầu tiên của bind đó
  • Hiển thị grabbing cursor khi kéo cửa sổ bằng Mod+LMB
  • niri msg action load-config-file được thêm tham số --path, cho phép chuyển sang tệp cấu hình khác trong lúc chạy
  • nested niri đã có hỗ trợ DMA-BUF, giúp tăng tốc phần cứng hoạt động trở lại ngay cả sau khi Mesa loại bỏ wl_drm
  • Đã loại bỏ phần padding mà niri từng thêm vào các popup layer-shell gần mép màn hình
  • Cũng bao gồm thay đổi trong cấu hình mặc định
    • Mod+M: maximize-window-to-edges
    • Mod+Shift+R: switch-preset-column-width-back
  • Đã thêm cờ debug force-disable-connectors-on-resume, cho phép buộc màn hình chuyển sang trạng thái blank khi chuyển TTY hoặc khôi phục từ chế độ ngủ
  • Đã sửa để các góc cửa sổ trong windowed fullscreen được xử lý vuông góc chính xác
  • Đã sửa lỗi màn hình tiếp tục bị vẽ lại liên tục khi overview đang mở
  • Đã tinh chỉnh nhẹ việc kết xuất gradient border relative-to=workspace-view trong lúc kéo tương tác
  • Đã tinh chỉnh cách hiển thị phím tắt diaeresis trong hộp thoại Important Hotkeys
  • Đã sửa mô tả expel-window-from-column trong niri msg action để khớp với hành vi thực tế là đẩy cửa sổ phía dưới ra ngoài
  • Đã sửa nhiều panic có thể xảy ra khi client cố dùng một output vừa bị gỡ gần đây
  • Đã sửa lỗi kết xuất bị hỏng khi clip-to-geometry được dùng cùng các client gắn bộ đệm y_invert
  • Đã sửa bản dựng OpenBSD
  • nested niri giờ sẽ đặt app-id cho chính cửa sổ của nó
  • Khi GPU mới được cắm vào, thiết lập debug ignore-drm-device sẽ được đánh giá lại để có thể tận dụng cả symbolic link /dev/dri/by-path/

Cập nhật theo Smithay

  • Cùng với bản cập nhật Smithay, nhiều cải tiến nền tảng cũng được đưa vào
    • Tự động chọn GPU được cải thiện trên một số thiết bị như máy Mac ARM
    • Asahi và Pinephone giờ có thể hoạt động ngay mà không cần cấu hình render-drm-device thủ công
    • Hoạt động của một số client layer-shell như wl_shimeji đã được cải thiện
    • Hỗ trợ dock có EDID màn hình được tải muộn đã được cải thiện
    • Chụp màn hình và screencast đã hoạt động trên các hệ Intel cũ
    • Đã sửa lỗi output cũ còn sót lại khi rút dock USB-C trong lúc máy đang ngủ
    • Đã sửa panic zxdg_exporter_v2 trên một số client
    • Đã sửa rò rỉ bộ nhớ ở các client không hủy giao thức clipboard một cách tường minh
    • Đã sửa các panic liên quan đến text-input content hint và purpose bắt đầu xuất hiện trong bản phát hành phát triển GTK 4.23
    • drag-and-drop, nhập văn bản IME, đa GPU và hiệu năng tổng thể cũng được cải thiện

Bài viết liên quan

1 bình luận

 
GN⁺ 11 giờ trước
Ý kiến trên Hacker News

  • Tôi thích Niri đến mức đã chuyển sang dùng từ khoảng 5 tháng trước, và từ đó tới nay cảm giác như đây là một trong những quyết định đúng đắn nhất kể từ khi rời Windows trong vài năm gần đây
    Tôi thực sự rất biết ơn tác giả
    Bộ dotfiles của tôi vốn có cả script cài đặt cho cấu hình công cụ CLI, chuyển theme các thứ, và giờ trên hệ Arch cũng đã hỗ trợ Niri đầy đủ
    Nếu muốn thử nhanh một môi trường desktop mới, https://github.com/nickjj/dotfiles là điểm khởi đầu khá ổn
    Tôi đang dùng nó cả trên máy desktop chính lẫn laptop mang đi đường

    • Tôi cũng vậy, và bộ đôi màn hình cong ultrawide với Niri đặc biệt hợp nhau
    • Cũng nên xem qua Nirimod
      Không chính thức nhưng thực sự rất xuất sắc
    • Omarchy đã thêm kiểu toggle chế độ scrollable theo từng workspace như thế này
      Nhấn Win/Cmd + L là chuyển qua lại giữa tiling và scrolling, và giờ tôi dùng nó rất thường xuyên

  • Nhờ Niri mà tôi lần đầu tiếp xúc với quản lý cửa sổ dựa trên cuộn, và thấy hợp ngay lập tức
    Gần đây OmniWM trên Mac đã có chế độ mô phỏng Niri đầy đủ theo từng workspace, may là cũng tương thích với Sequoia nên nó lập tức trở thành window manager chính của tôi
    [1] https://github.com/BarutSRB/OmniWM

    • Paneru là một công cụ mới trên macOS được làm ra đúng với mục đích mô phỏng Niri
    • Tôi cũng tương tự
      Ngay lần đầu biết tới cách làm của Niri là tôi đã rất thích, rồi cứ đi tìm thứ gì đó tương tự trên Mac
      Đây là bản hiện thực tốt nhất tôi từng dùng, tất nhiên vẫn có vài quirks lặt vặt nhưng ít nhất với tôi thì hoàn toàn đủ tốt để dùng hằng ngày
      Đặc biệt là tabbed columns rất tuyệt
      Xin gửi lời tán thưởng tới maintainer và các contributor

  • Nếu dùng Mac thì tôi khuyên OmniWM
    Nó không chỉ có layout kiểu Niri mà còn có cả layout gần với Hyprland hơn, và nhờ vậy trải nghiệm làm việc trên macOS của tôi dễ chịu hơn rất nhiều
    https://github.com/BarutSRB/OmniWM
    Trước đây khi mới bắt đầu dùng tôi cũng từng giới thiệu rồi, nhưng sau khi dùng tiếp thì thấy nó thực sự ổn và rất đáng để khuyên dùng

    • Xin lỗi nhưng video demo đó thuộc hàng tệ nhất tôi từng xem trong đời
      Xem xong chắc chẳng ai muốn thử phần mềm này, thậm chí nếu đã là người dùng rồi cũng có khi muốn xóa luôn

  • Tôi đang dùng PaperWM extension cho GNOME, và có lẽ Niri cũng lấy cảm hứng từ đây
    Đây rõ ràng là một cách làm việc thú vị, nhưng khi một workspace có quá 3 cửa sổ thì tôi thấy hơi bất tiện nên chưa thể nói là yêu hẳn
    Dù vậy tôi vẫn đang dùng nghiêm túc, và vì nó là GNOME extension nên có thể giữ nguyên phần còn lại của GNOME DE mà không cần cấu hình quá nhiều cũng là điểm hay

    • Có một thời gian tôi muốn chuyển sang Niri, nhưng quá trình chỉnh cấu hình bổ trợ lúc nào cũng tốn vài ngày
      Vì còn phải lo cả top bar, idle timeout, thông báo các thứ
      Nhưng gần đây tôi mới biết là đã có các desktop shell cho Wayland, cung cấp hầu hết những thứ người ta mong chờ ở môi trường như GNOME mà không cần tốn quá nhiều công sức
      Có đủ hộp thoại cài đặt, app tray, theo dõi tài nguyên, cả top bar nữa
      Giờ tôi dùng dank material shell, và việc có thể tự do phối desktop shell với compositor thực sự rất ngầu
    • Tôi cũng vậy, tôi thích việc PaperWM là một GNOME extension không xâm lấn
      Workflow nhìn chung đã tốt hơn, mà nhờ nó tôi còn gỡ được thêm hai ba extension khác như desktop grid

  • Tôi đã quen hẳn với kiểu tiling WM là nhảy nhanh qua lại giữa nhiều workspace fullscreen chuyên dụng và quản lý cửa sổ hoàn toàn bằng bàn phím
    Thường thì mỗi workspace tôi để một app hoặc một terminal mở tmux, thỉnh thoảng mới đặt hai app cạnh nhau
    Tôi thực sự tò mò là với những người chuyển sang Niri từ workflow tương tự, mô hình tư duy của họ thay đổi thế nào

    • Trên KDE, GNOME lẫn Niri tôi luôn dùng workspace theo hoạt động/dự án
      Kiểu một workspace cho Steam và wiki game, một workspace cho Emacs và trình duyệt tài liệu, một workspace cho Godot và các app làm game
      Điểm hay của Niri là gần như không có áp lực phải đóng bớt thứ gì đó khi bạn thấy số cửa sổ bắt đầu quá nhiều
      Tách ra để sắp xếp khá dễ
      Tôi không thật sự hiểu vì sao phải dùng workspace theo từng app
      Tôi cũng ghét chuyện trong một Firefox lại lẫn cả tab công việc lẫn tab sở thích
    • Tôi đã là người dùng tiling khá lâu và cấu hình cũng tương tự
      Từng dùng awesome, qtile, xmonad một thời gian ngắn, rồi i3, sau đó chuyển sang Wayland thì dùng sway, và cũng thử hyprland một chút
      Vấn đề tôi luôn gặp là khi quá 3 cửa sổ thì bố cục ngang không còn ổn, còn chia dọc thì mọi thứ bé quá
      Trong khi đó những lúc muốn mở một cửa sổ mới cạnh thứ đang đọc, hoặc bật biểu đồ ipython cạnh terminal, lại xảy ra khá thường xuyên
      Khi đó tôi либо phải gom chúng vào stacked layout, либо chuyển sang workspace mới, nên ma sát khá lớn và workflow liên tục bị ngắt bởi chuyện quản lý cửa sổ
      Với Niri, tôi chỉ việc mở cửa sổ mới là nó xuất hiện đúng chỗ cần, còn các cửa sổ khác vẫn nằm nguyên bên trái phải để cuộn tới
      Giờ workflow của tôi bừa hơn trước một chút, nhưng thực ra tôi lại thích vậy
      Các tiling WM truyền thống yêu cầu bạn phải sắp xếp và cũng giúp việc đó trở nên dễ dàng, còn trong Niri thì không nhất thiết phải dọn dẹp
      Thi thoảng không tìm thấy ngay cửa sổ mình cần thì tôi dùng overview, và còn gắn thêm tìm kiếm cửa sổ bằng rofi
      Lúc đầu tôi vẫn giữ thói quen đặt tên workspace từ thời sway, nhưng giờ thì không còn nữa
    • Tôi cũng chuyển từ KDE với workflow gần như y hệt
      Workspace 1 là terminal fullscreen mở zellij, 2 là trình duyệt, 3 là khoảng hai app chat, và tôi qua lại bằng phím tắt
      Ban đầu tôi dùng Niri vì nó nhẹ và khác Plasma, nhưng giờ thì workflow cũng đã thay đổi đôi chút
      Phần lớn cửa sổ tôi vẫn dùng ở kích thước gần full màn hình, và vẫn sắp xếp tương tự như 1 cho phát triển, 2 cho trình duyệt và thỉnh thoảng thêm mail reader, 3 cho app chat
      Nhưng giờ tôi mở cửa sổ terminal mới thường xuyên hơn nhiều để gõ lệnh ngắn hoặc để một tác vụ chạy lâu
      Trên KDE những cửa sổ như vậy thường chồng phía sau, còn giờ trong workspace 1 chúng nằm cạnh nhau
      Nghĩ lại thì kiểu qua lại bằng Alt-Tab giờ thấy khá tù túng, còn chuyển bằng Super-hjkl thì nhẹ nhàng hơn hẳn
      Tất nhiên tùy người, nhưng cảm giác cửa sổ nằm cạnh nhau thay vì đè lên nhau làm workflow nhẹ hơn rất nhiều
    • Thật ra cái đó trông giống kết hợp fullscreen với workspace hơn là tiling
      Với các WM xếp ô thủ công như i3 hay sway và một màn hình lớn, bạn có thể chia màn hình thành nhiều vùng làm việc rồi đặt vài app theo vai trò ở mỗi vùng để giảm số workspace cần dùng
      Scrolling là một workflow tương tự nhưng khác biệt, và đặc biệt hợp khi cần sự linh hoạt trên màn hình nhỏ
    • Tôi thấy một workspace cho một app không có nhiều ý nghĩa trong tiling WM
      Workflow đó hợp với floating WM hơn
      Điểm mạnh thật sự của tiling WM là việc cửa sổ được xếp ô thực sự, và với tôi bộ tam thánh là trình duyệt, editor và terminal cùng hiện ra một lúc
      Đồng thời phải có khả năng di chuyển theo không gian bằng super+hjkl hoặc các phím mũi tên
      Vì vậy workspace theo dự án thấy tự nhiên hơn nhiều và đúng chất tiling WM hơn
      Niri làm điều này tốt hơn hẳn vì nó mở cửa sổ mới sang bên phải mà không phá layout hiện tại
      Ví dụ mở một file PDF thì bạn vẫn giữ nguyên bố cục cũ và chuyển sang cửa sổ mới rất dễ dàng

  • Đây là các liên kết liên quan
    The dank case for scrolling window managers - https://news.ycombinator.com/item?id=46820468 - Jan 2026 (61 bình luận)
    Niri 25.11 released with alt-tab and other improvements - https://news.ycombinator.com/item?id=46097051 - Nov 2025 (1 bình luận)
    Niri – A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=45461500 - Oct 2025 (229 bình luận)
    The Future Is Niri - https://news.ycombinator.com/item?id=43342178 - March 2025 (216 bình luận)
    Niri: A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=37367687 - Sept 2023 (37 bình luận)

  • Nếu muốn thử NNN (Niri-Nix-Noctalia) dots thì có thể lấy flake của tôi
    https://github.com/MostlyKIGuess/nix-flake-public

    • Tôi đã dùng window manager vài năm nhưng cuối cùng vẫn quay lại desktop environment hoàn chỉnh vì rào cản phải tự chỉnh cả cấu hình ngoài WM
      Chỉ riêng mấy thứ như dark mode cũng đã tốn công rồi, nên Noctalia có vẻ đúng kiểu tôi từng muốn
      Cảm ơn vì đã nhắc tới

  • Tôi đang dùng nhánh wl-only của mangowm (dựa trên wlroots 0.20)
    Nó ăn ít tài nguyên hơn nhiều, có nhiều layout hơn và ít vấn đề hơn
    Phía Niri thì hiệu ứng hình ảnh có vẻ đẹp hơn, nhưng vẫn hoàn toàn đáng để thử một lần
    Nếu cần HDR thì vẫn phải chờ thêm
    https://github.com/mangowm/mango

    • Tôi tò mò là cụ thể ít vấn đề hơn ở điểm nào
      Với tôi thì Niri cực kỳ rock solid

  • Nghe như kiểu một thiên tài người Nga vừa làm ra thứ tốt hơn 100 triệu đô token Claude
    Chắc chắn không phải kiểu điên rồ tập thể gì đâu, nên mọi người cứ mua SPY đi

    • Có vẻ đúng là thiên tài thật
      Đọc release note thôi cũng đã thấy đẹp theo cách riêng của nó

  • Cuối năm ngoái tôi chuyển từ i3 sang Niri sau hơn 10 năm dùng i3
    Khả năng cuộn ngang không bị trói bởi kích thước màn hình, và số workspace không bị giới hạn bởi số phím tắt đã gán, mang lại cảm giác rất giải phóng
    Mức độ hoàn thiện về đồ họa cũng tốt
    Tuy vậy điều tôi vẫn thấy tiếc là lớp tương thích X là xwayland-satellite vẫn chưa hỗ trợ drag and drop giữa app X và app Wayland
    [1]: https://davidyat.es/2026/01/28/niri/
    [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

    • Tôi cũng ở tình huống tương tự
      Trước đây tôi luôn có thói quen để cùng một thứ ở cùng một workspace nên rất dễ nhớ, còn giờ thì bố cục bị phân tán ra nhiều chỗ
      Và tôi khá nhớ scratch
      Có lẽ chỉ cần chăm chỉnh cấu hình hơn một chút là giải quyết được, nhưng tôi vẫn chưa dành thời gian cho việc đó