Niri 26.04: स्क्रॉलिंग टाइलिंग Wayland compositor

 (github.com/niri-wm)
2 पॉइंट द्वारा GN⁺ 4 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्क्रॉलिंग टाइलिंग Wayland compositor में background blur, screencast, rendering और input handling के कई सुधार जोड़े गए हैं, जिससे इसकी परिपक्वता बढ़ी है
  • Background blur अब mainline में शामिल है, इसलिए ext-background-effect को सपोर्ट करने वाली window और layer-shell elements अलग niri settings के बिना भी blur अनुरोध कर सकती हैं, और niri-side rules से blur को force भी किया जा सकता है
  • Screencast में PipeWire और wlr-screencopy दोनों paths पर cursor handling, dynamic cast शुरू करने का तरीका, IPC query और force stop, multiple copy और resource release जैसी समस्याओं को सुधारा गया है
  • Rendering structure को iterator-based से push-based में दोबारा बनाया गया है, जिससे render list बनाने की गति प्रमुख machines पर 2–3 गुना और पुराने Eee PC पर 8 गुना तेज हुई है, साथ ही memory usage भी कम हुआ है
  • पुराने hardware और input environments तक में सुधार किए गए हैं, जैसे पुराने Intel systems पर screenshot·screencast, IME और GTK 4 popup conflicts, high polling rate mouse और tablet mapping, nested niri की DMA-BUF acceleration, जिससे वास्तविक उपयोग का दायरा बढ़ा है

मुख्य बदलाव

  • GitHub organization को personal account से niri-wm में स्थानांतरित किया गया है, और संबंधित projects को भी साथ में व्यवस्थित किया गया है
    • awesome-niri: संबंधित projects की सूची
    • artwork: badges और wallpapers का संग्रह
  • Packagers से जुड़े बदलाव भी शामिल हैं
    • न्यूनतम समर्थित Rust version बढ़ाकर 1.85 कर दिया गया है
    • niri.service अब niri binary path में /usr/bin/ को hardcode नहीं करता
    • dinit service file structure बदल गई है: 3bfa4a7

Background blur

  • Background blur अब mainline में आ गया है, और window तथा layer-shell components ext-background-effect protocol के जरिए blur का अनुरोध कर सकते हैं
    • अतिरिक्त niri settings के बिना भी कई shells और apps इसे तुरंत उपयोग कर सकते हैं
    • Dank Material Shell v1.4.5: settings में enable किया जा सकता है
    • Noctalia shell: settings और documentation उपलब्ध
    • Vicinae launcher support
    • foot v1.26: blur=true
    • kitty v0.46.2: background_blur 1
    • Ghostty: v1.4 में support अपेक्षित
    • Quickshell: v0.3 में support अपेक्षित
    • winit: v0.31 में support अपेक्षित
  • अगर app अभी ext-background-effect को support नहीं करता, तब भी window-rule और layer-rule के जरिए niri-side पर blur चालू किया जा सकता है
    • विस्तृत settings और constraints Window Effects documentation में दी गई हैं
    • niri में सेट किया गया blur सही geometry-corner-radius की जरूरत रखता है
    • यह complex surface shapes पर काम नहीं करता
  • xray blur और सामान्य blur दोनों उपलब्ध हैं, और default रूप से xray blur सक्षम है
    • xray blur wallpaper को सिर्फ एक बार blur करके static image की तरह reuse करता है, इसलिए यह काफी अधिक efficient है
    • यह केवल wallpaper बदलने पर दोबारा calculate होता है
    • Animated wallpapers में इसकी efficiency का लाभ कम हो जाता है
    • नए layer matcher से इसे top, overlay जैसे layers पर ही सामान्य blur लागू करने के लिए बदला जा सकता है
  • Blur feature को लागू करना इतना कठिन था कि इसके लिए rendering structure changes की जरूरत पड़ी
    • सामान्य blur frame के बीच में पहले से render हुए pixels को फिर से पढ़कर blur करता है और उसके बाद rendering जारी रखता है
    • xray blur के लिए सही background clipping सुनिश्चित करने हेतु window positions को rendering code में व्यापक रूप से पास करना पड़ा
    • Overview में xray blur support जोड़ते हुए भी overview को फिर से render न करने वाली उसकी प्रकृति बनाए रखनी पड़ी
    • इसे screencast blocked windows के साथ भी काम करना था
  • Blur के बिना केवल xray का अलग से उपयोग किया जा सकता है, और blur color banding को कम करने के लिए noise तथा saturation effects भी अलग से इस्तेमाल किए जा सकते हैं
  • नए popups block के जरिए window rule या layer rule में popup menus पर भी transparency और background effects लागू किए जा सकते हैं
    • GTK 4 के has-arrow=true popup जैसे non-rounded rectangle मामलों में shape कुछ अजीब लग सकती है
    • Web apps या Electron Wayland popups का उपयोग नहीं करते, इसलिए niri उन्हें handle नहीं कर सकता
    • जो clients ext-background-effect को सीधे implement करते हैं, वे अधिक जटिल blur shapes भी संभाल सकते हैं

Optional include

  • config include में optional include जोड़ा गया है
    • include optional=true "optional-config.kdl" की तरह लिखने पर file न होने पर भी config loading fail नहीं होती
    • अगर file नहीं है, तो हर config reload पर warning log दर्ज होता है, लेकिन config load होती रहती है
    • बाद में file बन जाए तो monitored change पकड़ा जाता है और config अपने-आप फिर से reload हो जाती है
    • अगर file मौजूद है लेकिन उसमें syntax error है, तो उसे अब भी parsing failure माना जाएगा
  • include path में ~ को home directory के रूप में expand किया जाता है
    • ~/file.kdl को /home/user/file.kdl में expand किया जाता है

Pointer warping और scroll

  • view को scroll करने वाले gesture के दौरान pointer अब screen के एक किनारे से विपरीत किनारे पर warp हो जाता है
    • यह Blender जैसा व्यवहार है
    • इससे monitor के किनारे के पास शुरू करने पर भी कई windows के बीच स्वाभाविक रूप से लगातार scroll किया जा सकता है

स्क्रीनकास्ट सुधार

  • niri के स्क्रीनकास्ट में PipeWire के जरिए xdg-desktop-portal-gnome और wlr-screencopy के जरिए, दोनों तरीकों में सुधार हुआ है

  • विंडो स्क्रीनकास्ट में कर्सर हैंडलिंग

    • PipeWire में अब कर्सर को सीधे वीडियो फ्रेम के अंदर ड्रॉ करने के बजाय कर्सर metadata का समर्थन है
      • वीडियो फ्रेम में कर्सर शामिल नहीं होता, बल्कि कर्सर आइकन और coordinates अलग buffer में भेजे जाते हैं
      • OBS या ब्राउज़र जैसे consumer अब कर्सर को खुद ड्रॉ करते हैं
    • यह monitor capture और window capture, दोनों में काम करता है
    • window capture में कर्सर सिर्फ तब दिखता है जब वह वास्तव में उस विंडो या उसके popup पर हो
    • drag-and-drop icon भी साथ में ड्रॉ होता है
    • implementation के दौरान PipeWire की memory corruption समस्या भी सामने आई और उसे ठीक किया गया
    • PipeWire के इरादे और libwebrtc जैसे consumer implementations के बीच असंगति भी पाई गई
    • जिन environments में परीक्षण किया गया, वहाँ यह सही तरह से काम करता है
    • screenshot-window show-pointer=true से window screenshot में भी pointer शामिल किया जा सकता है

  • Dynamic cast target शुरू करने का तरीका बदला

    • Dynamic cast target एक फीचर है जो keybind से स्क्रीनकास्ट target को तुरंत बदल देता है
    • पहले यह शुरू होते समय 1×1 काले pixel वाली video stream के रूप में खुलता था
    • अब पहला वास्तविक target चुने जाने तक video stream शुरू होने में देरी की जाती है
    • इससे Microsoft Teams में थोड़ी देर के लिए दिखने वाली 1×1 video की समस्या से बचा जा सकता है

  • Cast IPC

    • अब चल रहे स्क्रीनकास्ट को IPC के जरिए देखा जा सकता है
    • niri msg casts से active casts देखे जा सकते हैं
    • event stream में cast events को subscribe किया जा सकता है
    • Cast object type, current target और active state देता है
    • PipeWire स्क्रीनकास्ट node ID देता है, और wlr-screencopy client process ID देता है
    • DankMaterialShell पहले ही इस IPC से स्क्रीनकास्ट indicator दिखाता है
    • niri msg action stop-cast --session-id <ID> से PipeWire स्क्रीनकास्ट को जबरन बंद किया जा सकता है

  • wlr-screencopy से जुड़ी सीमाएँ और सुधार

    • wlr-screencopy में स्क्रीनकास्ट और screenshot को मज़बूती से अलग पहचानने का तरीका नहीं है, इसलिए कुछ heuristics की ज़रूरत पड़ती है
    • xdg-desktop-portal-wlr एक ही wlr-screencopy manager object को लगातार बनाए रखता है, इसलिए इसके खत्म होने का समय तुरंत पता लगाना कठिन है
    • ये समस्याएँ नए ext-image-copy-capture protocol में हल की गई हैं, लेकिन niri में यह अभी शामिल नहीं हुआ है

  • अन्य स्क्रीनकास्ट सुधार

    • damage copy के समय wlr-screencopy client कर्सर न चाहता हो तब भी उसके हमेशा शामिल हो जाने की समस्या ठीक की गई
    • damage वाले multi-frame copy को एक साथ request करने पर होने वाले व्यवहार को ठीक किया गया
    • कुछ स्थितियों में, जैसे client बंद हो जाने पर, niri का wlr-screencopy data release न होने की समस्या ठीक की गई
    • default PipeWire स्क्रीनकास्ट buffer की संख्या 16 से घटाकर 8 कर दी गई
    • pipewire-rs के use-after-free issue से बचने के लिए struct fields के क्रम को बदला गया
    • dynamic cast target को window पर बदलते समय एक frame तक z-order गलत render होने की समस्या ठीक की गई

एनीमेशन और विंडो व्यवहार

  • एनीमेशन synchronization अब और सटीक हो गई है
    • niri अलग-अलग animations को अलग से configure कर सकता है, लेकिन जहाँ उनका ठीक-ठीक मेल होना ज़रूरी हो, वहाँ उन्हें synchronized चलाया जाता है
    • window resize animation अब उससे ट्रिगर हुई horizontal view movement animation के साथ synchronize होती है
    • fullscreen या maximize हटाने पर view movement synchronization छूट जाने से विंडो तुरंत लौट आती थी, जबकि स्क्रीन धीरे-धीरे scroll होती थी; यह समस्या ठीक की गई
  • कुछ drag paths में दूसरी tiled windows की horizontal movement animation छूट जाने की समस्या ठीक की गई
    • यह maximize की गई विंडो को drag करके unmaximize करने, और अगर वह मूल रूप से floating विंडो थी तो उसे फिर से floating में लौटाने वाले व्यवहार से जुड़ा था
    • और monitor edge के पास drag करने पर बाएँ-दाएँ workspace scrolling logic के overlap से यह समस्या बनती थी
    • fix commit: df3f3979e936ed6800b4fbd55843bb0fe2554f15
  • workspace के सबसे बाएँ column को खींचकर बाहर निकालने और फिर छोड़ने पर उसके अपनी जगह के बजाय दाईं ओर चले जाने की समस्या भी ठीक की गई
  • configuration error notifications की display duration अब animation slowdown/speedup settings से प्रभावित नहीं होती

IME और popup

  • GTK 4 popup input fields और IME के साथ काम न करने वाली पुरानी समस्या का workaround लागू किया गया
    • Fcitx5 जैसे IME चालू होने पर text input popup खोला नहीं जा सकता था
    • popup pointer और keyboard grab लेता था, और IME भी keyboard grab का उपयोग करता है, इसलिए टकराव होता था
    • niri popup grab छोड़ देता था, जिससे popup तुरंत बंद हो जाता था
    • Smithay की संरचना को पूरी तरह बदले बिना काम कराने के लिए कुछ checks को ढीला किया गया
    • अब IME उपयोगकर्ता Nautilus में file rename जैसे काम कर सकते हैं

drag-and-drop और input devices

  • drag-and-drop के दौरान Escape दबाकर काम रद्द किया जा सकता है
  • input devices से जुड़े कई और fixes भी शामिल हैं
    • high-polling-rate mouse के साथ hide-after-inactive-ms या idle monitoring daemon का उपयोग करने पर समय के साथ धीमा पड़ने की समस्या ठीक की गई
    • libwayland-server v1.23 या बाद के संस्करण में Wayland buffer size बढ़ाई गई है, ताकि unresponsive window के ऊपर high-polling-rate mouse हिलाने पर विंडो जल्दी crash न हो
    • map-to-focused-output tablet option जोड़ा गया है, जिससे किसी तय single output के बजाय मौजूदा focused output पर map किया जा सकता है
    • workspace की सबसे ऊपरी pixel line पर कर्सर maximize की गई विंडो को हमेशा सही तरह point नहीं कर पाता था; यह समस्या ठीक की गई
    • Alt-Tab के स्क्रीन पर दिखने से पहले mouse input पर प्रतिक्रिया देने की समस्या ठीक की गई
    • trackball का on-button-down scroll अब overview में भी काम करता है
    • custom .xkb keymap लोड करने के बाद भी Num Lock state बनी रहती है
    • tmux के जरिए किसी दूसरे TTY से शुरू करने पर input devices बिल्कुल काम न करने की समस्या ठीक की गई
    • libinput plugins loading को सक्षम किया गया

GPU प्रोफाइलिंग और रेंडरिंग ऑप्टिमाइज़ेशन

  • Smithay और niri में इस्तेमाल होने वाले Tracy में GPU प्रोफाइलिंग इंटीग्रेशन जोड़ा गया
    • GPU timestamp query सबमिट करने, पूरे हुए मान इकट्ठा करने और उन्हें Tracy को भेजने वाला काम Smithay में जोड़ा गया: वर्क PR
    • Smithay के अंदरूनी GPU काम और compositor के अपने GPU काम, दोनों के लिए सेक्शन मार्किंग अब संभव है
    • एक ही फ्रेम में DRM buffer rendering और PipeWire screencast buffer rendering कैसे overlap करते हैं, इसे ट्रैक किया जा सकता है
    • multi-GPU सिस्टम में GPU-वार track भी देखे जा सकते हैं
    • यह सत्यापित किया जा सका कि blur performance अपेक्षा से धीमी नहीं है, और GPU rendering bottleneck से होने वाले dropped frame का diagnosis भी आसान हो गया
  • render list बनाने का तरीका iterator-आधारित से push-आधारित ढांचे में बदला गया
    • पहले -> impl Iterator<Item = ...> रूप में render elements को जोड़ा जाता था
    • condition branching, lifetime, &self borrowing, &mut Renderer के साथ टकराव, बीच में Vec allocation, crate boundary जैसी कई जटिलताएँ थीं
    • नई संरचना में render function push: &mut dyn FnMut(Element) लेता है और elements को push करता है
    • बीच के function, ऊपर वाले push को wrap करने वाले closure के जरिए पुराना logic बनाए रख सकते हैं
    • अस्थायी Vec हट गया और borrowing की समस्या भी खत्म हो गई
    • niri में iterator के early termination का फायदा वास्तव में जरूरी नहीं था
  • इस refactoring से render list बनाने की गति काफी बढ़ गई
    • मुख्य मशीन पर 2~3 गुना तेजी मिली
    • पुराने Eee PC पर 8 गुना तेजी मिली
    • render list निर्माण, असली GPU rendering time नहीं है, लेकिन स्क्रीन दोबारा draw न होने पर भी यह अक्सर चलता है, इसलिए सुधार का असर बड़ा है
    • memory usage भी घटा, और नए path में allocation ज्यादातर output vector के बढ़ने तक सीमित रह गई
    • विस्तृत motivation और diff PR में देखे जा सकते हैं

पुराने हार्डवेयर का समर्थन

  • पुराने Intel laptop पर screenshot fail होने की वजह Smithay का गलत OpenGL enum value निकली, और इसे ठीक कर दिया गया: कारण विश्लेषण PR
  • niri shader को भी थोड़ा optimize किया गया, ताकि बहुत पुराने ASUS Eee PC के सीमित GPU पर भी
    • window resize animation
    • compositor rounded corners
    • काम कर सकें

अन्य सुधार

  • कुछ सिस्टम में खास apps बंद होने के बाद होने वाली VRAM leak समस्या को ठीक किया गया
  • ext-foreign-toplevel-list protocol जोड़ा गया, जिससे Quickshell आदि में Wayland window object और niri IPC window ID को जोड़ना आसान हो गया
  • config में duplicate bind error आने पर उसी bind की पहली definition की जगह भी साथ में दिखाई जाती है
  • Mod+LMB से window drag करते समय grabbing cursor दिखाया जाता है
  • niri msg action load-config-file में --path argument जोड़ा गया, जिससे runtime में दूसरी config file पर स्विच किया जा सकता है
  • nested niri में DMA-BUF support जोड़ा गया, जिससे Mesa के wl_drm हटने के बाद भी hardware acceleration फिर से काम करता है
  • monitor किनारों के पास layer-shell popup में niri द्वारा जोड़ा जाने वाला padding हटा दिया गया
  • default config में बदलाव भी शामिल हैं
    • Mod+M: maximize-window-to-edges
    • Mod+Shift+R: switch-preset-column-width-back
  • force-disable-connectors-on-resume debug flag जोड़ा गया, जिससे TTY switch या suspend से resume पर स्क्रीन को जबरन blank किया जा सकता है
  • windowed fullscreen में window के corners सही समकोण में दिखें, इसके लिए सुधार किया गया
  • overview खुले रहने के दौरान स्क्रीन के लगातार redraw होते रहने की समस्या को ठीक किया गया
  • interactive drag के दौरान relative-to=workspace-view gradient border rendering को थोड़ा ठीक किया गया
  • Important Hotkeys dialog में diaeresis shortcut rendering को सुधारा गया
  • niri msg action में expel-window-from-column के विवरण को वास्तविक व्यवहार के अनुसार नीचे वाली window को बाहर करने के रूप में ठीक किया गया
  • हाल ही में हटाए गए output को client इस्तेमाल करने की कोशिश करे तो होने वाले कई panic ठीक किए गए
  • clip-to-geometry को y_invert buffer attach करने वाले client के साथ इस्तेमाल करने पर rendering टूटने की समस्या ठीक की गई
  • OpenBSD build को ठीक किया गया
  • nested niri अब अपनी window का app-id सेट करता है
  • नया GPU जोड़े जाने पर ignore-drm-device debug setting का फिर से मूल्यांकन किया जाता है, ताकि /dev/dri/by-path/ symbolic link का भी उपयोग हो सके

Smithay अपडेट शामिल

  • Smithay अपडेट के साथ कई बुनियादी सुधार भी आए
    • ARM Mac जैसे कुछ devices पर automatic GPU selection बेहतर हुआ
    • Asahi और Pinephone अब बिना मैनुअल render-drm-device setting के सीधे काम कर सकते हैं
    • wl_shimeji जैसे कुछ layer-shell clients का व्यवहार बेहतर हुआ
    • उन docks के लिए support बेहतर हुआ जिनमें monitor EDID देर से load होता है
    • पुराने Intel सिस्टम में screenshot और screencast काम करते हैं
    • suspend के दौरान USB-C dock हटाने पर पुराने output बचे रहने की समस्या ठीक की गई
    • कुछ clients में zxdg_exporter_v2 panic ठीक किया गया
    • clipboard protocol को स्पष्ट रूप से destroy न करने वाले clients की memory leak ठीक की गई
    • GTK 4.23 development release में शुरू हुए text-input content hint, purpose से जुड़े panic ठीक किए गए
    • drag-and-drop, IME text input, multi-GPU और overall performance में भी सुधार हुआ

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 일 전
Hacker News की राय

  • Niri इतना पसंद आया कि करीब 5 महीने पहले इस पर स्विच किया, और तब से यह हाल के कुछ वर्षों में Windows छोड़ने के बाद लिया गया मेरा सबसे अच्छा फैसला लगता है
    लेखक के लिए सच में बहुत आभार है
    मेरे dotfiles में पहले CLI टूल्स की settings, theme switching वगैरह के लिए install scripts शामिल थीं, और अब Arch-आधारित सिस्टम्स पर Niri भी पूरी तरह supported है
    अगर आप जल्दी कोई नया desktop environment आज़माना चाहते हैं, तो https://github.com/nickjj/dotfiles अच्छी शुरुआत है
    मैं इसे अपने main desktop और travel laptop दोनों पर इस्तेमाल कर रहा हूँ

    • मेरा भी यही अनुभव है, और ultrawide curved monitor के साथ Niri का combo खास तौर पर बहुत बढ़िया है
    • Nirimod भी ज़रूर देखना चाहिए
      unofficial है, लेकिन सच में शानदार है
    • Omarchy ने इसी तरह का workspace-per scrollable mode toggle जोड़ा है
      Win/Cmd + L दबाने पर tiling और scrolling के बीच switch होता है, और मैं अब इसे बहुत बार इस्तेमाल करता हूँ

  • Niri की वजह से मैंने पहली बार scroll-based window management देखा, और यह तुरंत समझ में आ गया
    हाल ही में Mac के लिए OmniWM में workspace-per पूरा Niri emulation mode आया है, और अच्छी बात यह है कि यह Sequoia के साथ भी compatible है, इसलिए यह तुरंत मेरा main window manager बन गया
    [1] https://github.com/BarutSRB/OmniWM

    • Paneru macOS पर Niri जैसा behavior देने के लिए उसी उद्देश्य से बना एक नया टूल है
    • मेरा भी कुछ ऐसा ही अनुभव है
      जब पहली बार Niri का तरीका पता चला तो बहुत पसंद आया, और तब से Mac पर वैसी ही किसी चीज़ की तलाश थी
      अब तक जो इस्तेमाल किया है, उनमें यह सबसे अच्छा implementation है, और हाँ कुछ छोटे-मोटे quirks हैं, लेकिन कम से कम मेरे लिए यह daily driver के तौर पर पूरी तरह काम का है
      खासकर tabbed columns बहुत अच्छे हैं
      maintainer और contributors के लिए ज़ोरदार तालियाँ

  • अगर आप Mac इस्तेमाल करते हैं तो OmniWM recommend करूँगा
    इसमें सिर्फ Niri-style layout ही नहीं, बल्कि Hyprland के ज़्यादा करीब layouts भी हैं, और इससे macOS पर काम करना काफी बेहतर हो गया है
    https://github.com/BarutSRB/OmniWM
    जब मैंने इसे पहली बार casually इस्तेमाल करना शुरू किया था तब भी पोस्ट किया था, लेकिन लगातार इस्तेमाल करने के बाद लगा कि यह सच में अच्छा है और ज़ोरदार recommendation के लायक है

    • माफ़ कीजिए, लेकिन demo video मेरी ज़िंदगी की देखी हुई सबसे खराब demo videos में से एक है
      उसे देखने के बाद किसी का भी यह software आज़माने का मन नहीं करेगा, बल्कि अगर कोई पहले से user हो तो उसे भी uninstall करने का मन हो सकता है

  • मैं GNOME के लिए PaperWM extension इस्तेमाल कर रहा हूँ, और शायद Niri ने भी यहीं से inspiration लिया है
    यह निश्चित रूप से एक दिलचस्प workflow है, लेकिन एक workspace में 3 से ज़्यादा windows हो जाएँ तो यह थोड़ा झंझट वाला लगने लगता है, इसलिए मैं इसे पूरी तरह प्यार नहीं कर पाया
    फिर भी मैं इसे ठीक से इस्तेमाल कर रहा हूँ, और GNOME extension होने की वजह से बिना बहुत ज़्यादा setup के बाकी GNOME DE वैसा ही इस्तेमाल कर पाना अच्छा है

    • मैं कुछ समय से Niri पर जाना चाहता था, लेकिन अतिरिक्त setup को ठीक करने में हमेशा कई दिन लग जाते थे
      क्योंकि top bar, idle timeout, notifications जैसी चीज़ें भी संभालनी पड़ती थीं
      लेकिन हाल ही में पता चला कि Wayland के लिए desktop shells भी हैं, जो GNOME जैसे environment से अपेक्षित ज़्यादातर चीज़ें बिना बहुत मेहनत के दे देते हैं
      इनमें settings dialogs, app tray, resource monitoring, top bar सब शामिल हैं
      अभी मैं dank material shell इस्तेमाल कर रहा हूँ, और यह बात सच में कमाल की लगती है कि आप desktop shell और compositor को अपनी मर्ज़ी से mix and match कर सकते हैं
    • मेरा भी यही अनुभव है, और PaperWM के non-invasive GNOME extension होने की बात मुझे बहुत पसंद है
      workflow कुल मिलाकर बेहतर हुआ ही है, साथ ही इसकी वजह से desktop grid जैसे दो-तीन दूसरे extensions भी हटाए जा सके

  • मैं कई dedicated fullscreen workspaces के बीच तेज़ी से घूमने और सिर्फ keyboard से windows manage करने वाले tiling WM workflow का पूरी तरह आदी हो चुका हूँ
    आम तौर पर हर workspace में एक app या tmux खुला एक terminal रखता हूँ, और कभी-कभार ही दो apps को साथ-साथ रखता हूँ
    ऐसे मिलते-जुलते workflow से Niri पर आने वालों की mental model कैसे बदलती है, यह जानने में सच में दिलचस्पी है

    • KDE, GNOME और Niri तीनों में मैं हमेशा activity/project-based workspaces इस्तेमाल करता आया हूँ
      जैसे एक workspace में Steam और game wiki, दूसरे में Emacs और document browser, और किसी में Godot व game-dev apps
      Niri की अच्छी बात यह है कि windows ज़्यादा हो जाने पर कुछ बंद करने का दबाव लगभग महसूस ही नहीं होता
      चीज़ों को अलग-अलग करके व्यवस्थित करना काफी आसान है
      app-per-workspace क्यों इस्तेमाल किया जाए, यह मुझे समझ नहीं आता
      एक ही Firefox में काम और शौक के tabs मिले-जुले रहना भी मुझे पसंद नहीं
    • मैं काफी समय से tiling user रहा हूँ और मेरा setup भी ऐसा ही था
      awesome, qtile, थोड़ी देर xmonad, फिर i3, और Wayland पर जाते हुए sway, साथ में थोड़ा hyprland भी इस्तेमाल किया
      हमेशा दिक्कत यह रही कि windows 3 से ज़्यादा होते ही horizontal arrangement ठीक से काम नहीं करता, और vertical split बहुत छोटे हो जाते हैं
      दूसरी तरफ, कई बार ऐसा होता था कि जो चीज़ मैं पढ़ रहा हूँ उसके बगल में नई window खोलनी है, या terminal के पास ipython plot रखना है
      लेकिन हर बार stacked layout में group करना या नए workspace में भेजना पड़ता था, जिससे काफी friction होता था और window management की वजह से काम का flow टूट जाता था
      Niri में नई window बस खोल दो, वह ज़रूरी जगह पर आ जाती है, और बाकी windows बाएँ-दाएँ वैसे ही रहती हैं, जिन तक scroll करके पहुँचा जा सकता है
      अब मेरा workflow पहले से थोड़ा ज़्यादा messy हो गया है, लेकिन अजीब बात यह है कि यही मुझे पसंद है
      पुराने tiling WM सफ़ाई/organization माँगते भी थे और उसे आसान भी बनाते थे, लेकिन Niri में ज़रूरी नहीं कि आप सब कुछ व्यवस्थित करें ही
      कभी-कभी window तुरंत नहीं मिलती तो मैं overview इस्तेमाल करता हूँ, और मैंने rofi के साथ window search भी जोड़ रखा है
      शुरुआत में sway के दिनों की आदत से named workspaces इस्तेमाल करता रहा, लेकिन अब नहीं करता
    • मैं KDE से लगभग बिल्कुल ऐसे ही workflow के साथ आया हूँ
      workspace 1 में zellij के साथ fullscreen terminal, 2 में browser, 3 में दो chat apps वगैरह रहते थे, और मैं shortcut keys से इनके बीच जाता था
      शुरुआत में मैंने Niri सिर्फ इसलिए इस्तेमाल किया क्योंकि यह Plasma से हल्का और अलग था, लेकिन अब workflow भी थोड़ा बदल गया है
      ज़्यादातर windows अभी भी लगभग screen-size में ही रखता हूँ, और 1 को dev, 2 को browser व कभी-कभार mail reader, 3 को chat apps की तरह लगभग वैसा ही organize करता हूँ
      लेकिन अब छोटे commands चलाने या लंबे समय तक चलने वाले tasks खुले रखने के लिए नई terminal windows कहीं ज़्यादा बार खोलता हूँ
      KDE में ये windows पीछे overlap होकर रहती थीं, लेकिन अब 1 के अंदर साथ-साथ रखी रहती हैं
      पीछे मुड़कर देखता हूँ तो Alt-Tab वाला तरीका अब काफी घुटा-घुटा लगता है, और Super-hjkl से इधर-उधर जाना बहुत हल्का महसूस होता है
      बेशक यह हर किसी के लिए अलग हो सकता है, लेकिन windows के overlap होने के बजाय बगल में रखे जाने का एहसास workflow को ज़्यादा हल्का बनाता है
    • यह असल में tiling से ज़्यादा fullscreen और workspaces के combination जैसा लगता है
      i3 या sway जैसे manual tiling WM और बड़े monitor के साथ आप screen को कई work areas में बाँटकर हर area में अलग भूमिका वाले कई apps रख सकते हैं, जिससे workspaces की संख्या घट सकती है
      scrolling इससे मिलता-जुलता, लेकिन अलग workflow है, और खासकर छोटे screens पर जहाँ flexibility ज़रूरी हो, वहाँ यह अच्छा बैठता है
    • एक app के लिए एक workspace मुझे tiling WM में खास मायने रखता नहीं लगता
      वह workflow floating WM के लिए ज़्यादा उपयुक्त है
      tiling WM की असली ताकत windows को सच में tile करने में है, और मेरे लिए browser, editor, terminal की holy trinity सबसे अहम है
      और super+hjkl या arrow keys से spatial movement कर पाना ज़रूरी है
      इसलिए project-based workspaces मुझे कहीं ज़्यादा natural लगते हैं, और वही असली tiling WM वाला workflow महसूस होता है
      Niri यह और बेहतर करता है क्योंकि यह नई windows को दाईं ओर खोलता है और current layout को नहीं बिगाड़ता
      उदाहरण के लिए, PDF खोलने पर भी मौजूदा arrangement बना रहता है और आप आसानी से नई window पर जा सकते हैं

  • कुछ संबंधित links
    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 के बाहर की settings तक खुद संभालने की रुकावट की वजह से आखिरकार वापस full desktop environment पर लौट गया
      dark mode जैसी चीज़ों में भी बहुत मेहनत लगती थी, लेकिन Noctalia मुझे ठीक उसी दिशा में जाती हुई लगती है जैसी मैं चाहता था
      इसका ज़िक्र करने के लिए धन्यवाद

  • मैं mangowm की wl-only branch (wlroots 0.20 पर आधारित) इस्तेमाल कर रहा हूँ
    यह काफी कम resources खाती है, layouts भी ज़्यादा हैं, और issues भी कम हैं
    Niri की visual polish ज़रूर बेहतर लगती है, लेकिन इसे एक बार आज़माना बनता है
    अगर HDR चाहिए तो अभी इंतज़ार करना होगा
    https://github.com/mangowm/mango

    • कौन-से issues कम हैं, यह जानने की जिज्ञासा है
      मेरे लिए तो Niri सच में rock solid रहा है

  • यह तो ऐसा लगता है जैसे किसी Russian genius ने 100 million dollars के Claude tokens से बेहतर चीज़ बना दी हो
    बिल्कुल भी collective insanity नहीं है, इसलिए सबको SPY खरीदने को कहा जा रहा है

    • लगता है वह सच में genius है
      release notes पढ़ो, वे अपने-आप में खूबसूरत लगती हैं

  • पिछले साल के आखिर में मैं i3 पर 10 साल से ज़्यादा बिताने के बाद Niri पर आया
    horizontal scrolling जो monitor size से बंधी नहीं है, और workspaces की संख्या जो तय किए गए shortcuts की गिनती से सीमित नहीं है, दोनों बहुत मुक्त महसूस कराते हैं
    graphics के मामले में भी इसकी polish अच्छी है
    लेकिन एक कमी अब भी है: X compatibility layer xwayland-satellite अभी X apps और Wayland apps के बीच drag and drop support नहीं करती
    [1]: https://davidyat.es/2026/01/28/niri/
    [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

    • मेरी भी स्थिति कुछ ऐसी ही है
      पहले मुझे आसानी से याद रहता था क्योंकि मैं हमेशा वही चीज़ें उन्हीं workspaces में रखता था, लेकिन अब layout इधर-उधर बिखर जाता है
      और scratch की कमी काफी गहराई से महसूस होती है
      लगता है कि थोड़ा और मेहनत से config tweak करूँ तो शायद हल निकल आए, लेकिन अभी तक उस पर समय नहीं लगाया है