Xfwl4 – Xfce के लिए Wayland compositor रोडमैप

 (alexxcons.github.io)
1 पॉइंट द्वारा GN⁺ 2026-01-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Xfce टीम ने Wayland-आधारित नए compositor 'xfwl4' के विकास की योजना सार्वजनिक की, जिसमें community donations का उपयोग करते हुए core developer Brian Tarricone नेतृत्व करेंगे
  • लक्ष्य मौजूदा xfwm4 जैसी ही functionality और user experience देना है, और transition की निरंतरता के लिए settings dialog और xfconf configuration को फिर से इस्तेमाल किया जाएगा
  • Rust और smithay framework पर आधारित यह पूरी तरह नया codebase होगा, जो memory safety और customized graphics·input pipeline प्रदान करेगा
  • प्रोजेक्ट के दायरे में session management संरचना में बदलाव, XWayland और xdg-session-management support, CI build system में सुधार शामिल हैं
  • यह Xfce के Wayland transition के लिए एक अहम निवेश है, और पहला development release इसी वर्ष जारी होने की उम्मीद है

Xfce का नया Wayland compositor प्लान

  • Xfce टीम ने community donations का उपयोग करते हुए नए Wayland compositor 'xfwl4' का विकास शुरू किया है
    • विकास की जिम्मेदारी लंबे समय से core contributor रहे Brian Tarricone संभाल रहे हैं
    • project fund का एक बड़ा हिस्सा इस विकास पर खर्च किया जाएगा
  • लक्ष्य है कि xfwm4 जैसी ही functionality और behavior को Wayland environment में लागू किया जाए
    • मौजूदा xfwm4 settings dialog और xfconf settings को ज्यों का त्यों उपयोग करके user experience में consistency बनाए रखी जाएगी
  • xfwl4 मौजूदा xfwm4 code पर आधारित नहीं है, बल्कि इसे Rust में पूरी तरह नए सिरे से लिखा जा रहा है
    • यह smithay library पर बनाया जा रहा है

मौजूदा code को फिर से इस्तेमाल करने के बजाय rewrite करने का फैसला क्यों लिया गया

  • शुरुआत में xfwm4 code में बदलाव कर X11 और Wayland दोनों को साथ support करने की योजना थी, लेकिन कई कारणों से इसे उपयुक्त नहीं माना गया
    • xfwm4 की संरचना X11 पर निर्भर है, इसलिए generalized interface लागू करना कठिन है
    • refactoring के दौरान X11 bugs आने का जोखिम ज्यादा है
    • Wayland में supported न होने वाले X11 concepts मौजूद हैं, जिससे code maintenance जटिल हो जाती है
    • मौजूदा code का उपयोग करने पर C language और wlroots पर निर्भर रहना पड़ता
  • अलग codebase में development करने से xfwm4 की stability बनाए रखते हुए Wayland पर experimental development साथ-साथ संभव है

smithay चुनने के कारण

  • Brian Tarricone ने wlroots और smithay की तुलना करने के बाद smithay को चुना
    • smithay अधिकांश आधिकारिक Wayland protocol extensions के साथ wlroots·KDE protocols को support करता है
    • high-level abstraction न होने के कारण graphics·input pipeline पर बारीक नियंत्रण संभव है
    • इसकी documentation बेहतर है, और Rust के उपयोग से memory-related bugs और crashes का जोखिम कम होता है
    • developer की Rust के प्रति प्राथमिकता भी एक कारण है
    • wlroots C में लिखा गया है, इसलिए Rust bindings लिखना कठिन है

प्रोजेक्ट का दायरा और तकनीकी चुनौतियाँ

  • xfwm4 feature parity हासिल करने के अलावा निम्न कार्य भी शामिल हैं
    • Wayland environment में compositor को session root बनना पड़ता है, इसलिए session startup संरचना में बदलाव जरूरी है
    • xdg-session-management protocol support जोड़ा जाएगा
    • XWayland support शामिल है
    • CI container build system को meson-आधारित ऐसे setup में upgrade किया जाएगा जो Rust code build कर सके
  • Brian Tarricone ने development शुरू कर दिया है, और पहला development release इसी वर्ष जारी होने की योजना है

कम्युनिटी और समर्थन

  • यह प्रोजेक्ट Open Collective US और EU sponsors की donations की वजह से संभव हुआ है
  • development progress और technical details GitLab के xfwl4 issue और source code repository में देखे जा सकते हैं
  • संबंधित पूछताछ Matrix channel #xfce-dev के जरिए की जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2026-01-29
Hacker News की राय

  • सुना है कि xfwl4 का लक्ष्य xfwm4 के उसी फीचर सेट और व्यवहार को हासिल करना है
    लेकिन X11 और Wayland के संरचनात्मक अंतर को देखते हुए, यह जानना दिलचस्प है कि ‘व्यवहार’ की व्याख्या कितनी सख्ती से की जाएगी
    उदाहरण के लिए, focus stealing रोकना X11 में जटिल heuristics और timestamp जाँच की मांग करता है, जबकि Wayland में compositor पूरी तरह focus को नियंत्रित करता है
    आखिरकार, पुराने heuristics वाले एहसास को बनाए रखते हुए Wayland के permission model के अनुरूप नई policy डिज़ाइन करनी होगी
    एक और दिलचस्प बिंदु है compositing अनिवार्य होने से आने वाली latency। क्या low-end hardware पर X11 के non-compositing mode जैसी responsiveness मिल पाएगी?

    • मैं xfwl4 डेवलपर हूँ। “जितना संभव हो उतना समान” का मतलब बिल्कुल वही है। पूरी तरह एक जैसा होना संभव नहीं, लेकिन हम इसे यथासंभव करीब लाने वाले हैं
      focus stealing रोकने के मामले में Wayland शायद और भी संगत व्यवहार दे सकता है। Xfwm4 heuristics-आधारित था इसलिए कभी-कभी गलत काम करता था, लेकिन Wayland का xdg-activation मॉडल कहीं अधिक स्पष्ट है
      performance के मामले में, आधुनिक hardware पर बड़ा अंतर नहीं दिखना चाहिए, लेकिन बहुत पुराने डिवाइसों पर यह बोझ बन सकता है। असल में, ज़्यादा testing के बाद ही पक्का कहा जा सकेगा
    • मैंने पहले 400MHz Pentium II + GeForce 2 पर xfwm compositor चलाया था और कोई समस्या नहीं हुई
      compositing का असली बोझ लगभग सिर्फ vsync wait time ही है। अगर सिस्टम Pentium Classic स्तर का नहीं है, तो ठीक रहना चाहिए
    • ईमानदारी से कारण बताना अच्छा लगा। Rust अपनाने से build tooling या ecosystem integration में कुछ friction आ सकता है, जैसे किसी language island की तरह, लेकिन फिर भी GNOME की तुलना में XFCE मुझे हमेशा कहीं ज़्यादा पसंद आया है
    • compositing को ज़रूरी नहीं कि vsync के साथ ही किया जाए। client जब नया content भेजे, उसी समय display को अपडेट किया जा सकता है
    • आजकल सस्ते Intel GPU पर भी compositor overhead लगभग समस्या नहीं है। अपवाद सिर्फ वे लोग हैं जो 20 साल पुराने laptop इस्तेमाल कर रहे हैं

  • उम्मीद है कि XFCE अब भी हल्का desktop बना रहेगा
    मुझे KDE पसंद है, लेकिन उसे हल्का कहना मुश्किल है
    Wayland और Rust दोनों को मैं सकारात्मक रूप से देखता हूँ; Wayland भविष्य की दिशा है और Rust crash रोकने में मददगार हो सकता है
    लेकिन XFCE का पारंपरिक user base काफ़ी conservative है, इसलिए नई तकनीकों को लेकर संदेह होना स्वाभाविक है

    • 2007 से XFCE इस्तेमाल करने वाले के रूप में कहूँ तो, users भाषा या technology से ज़्यादा “बस यह ठीक से काम करे” चाहते हैं
      Wayland में बदलाव अपरिहार्य है, थोड़ी शिकायतें होंगी, लेकिन यह बिना किसी बड़े झटके के आगे बढ़ जाएगा
      X11 पर अड़े रहने वाले आखिरकार अल्पसंख्यक रह जाएँगे। मुझे XFCE टीम पर भरोसा है
    • मुझे समझ नहीं आता कि Wayland “भविष्य” जैसा क्यों लगता है। उल्टा यह feature regression जैसा महसूस होता है
      पहले से ठीक चल रहे GUI के होते हुए Wayland अनावश्यक जटिलता और compatibility समस्याएँ पैदा कर रहा है
      आम तौर पर सरल protocols लंबे समय तक टिकते हैं, और Wayland उसका उल्टा लगता है
    • मेरा रुख है: “जिसे ठीक करने की ज़रूरत नहीं, उसे ठीक मत करो”
      XFCE पहले से तेज़ और स्थिर है। अगर Wayland पर जाने से यह धीमा हो गया, तो इसकी सबसे बड़ी ताकत ही खत्म हो जाएगी
    • मुझे लगता है XFCE का Wayland migration समय लेगा
      यह community stability को प्राथमिकता देती है, इसलिए शायद X11 को default बनाए रखेगी और पूरी feature parity मिलने पर ही Wayland की ओर बढ़ेगी
    • लंबे समय से XFCE user होने के नाते, जब तक X11 को जल्दबाज़ी में हटाया नहीं जाता, मैं इस बदलाव को सकारात्मक रूप में देखता हूँ
      उम्मीद है कि जब कभी Wayland पर जाना ज़रूरी हो, तब भी मैं XFCE का इस्तेमाल जारी रख सकूँगा

  • मुझे लगता है कि यह प्रोजेक्ट खुद दिखाता है कि Wayland सही दिशा है
    Xorg एक single implementation था, लेकिन Wayland ने कई तरह के library ecosystems (wlroots, Smithay आदि) पैदा किए हैं
    इसी वजह से एक अकेला प्रोजेक्ट भी कुछ महीनों में developer preview जारी कर सकता है
    इस तरह की प्रतिस्पर्धा open source ecosystem को आगे बढ़ाएगी

    • क्योंकि Wayland सिर्फ low-level functionality देता है, इसलिए common desktop interfaces जल्दी-जल्दी बनाने पड़े
      लेकिन यह प्रक्रिया कुछ ज़्यादा ही जल्दबाज़ी में हुई, इसलिए integration कमज़ोर है। एक पूर्ण Linux desktop API को परिपक्व होने में शायद 10 साल और लगेंगे
    • कई implementations बनने से प्रतिस्पर्धा तो आती है, लेकिन maintainers की कमी के कारण feature gaps और burnout भी हो सकते हैं
      मेरे हिसाब से libcompositor का न होना Wayland की सबसे बड़ी गलती थी
    • code duplication ज़रूर बढ़ेगा, लेकिन बदले में हर टीम अपनी दर्शनशास्त्र के अनुरूप implementation बना सकेगी
      XFCE टीम क्या तैयार करती है, यह देखने में दिलचस्पी है
    • इस तर्क से मुझे वह समय याद आता है जब Rails का बहुत ज़्यादा इस्तेमाल होता था
      stack सुविधाजनक होता है, लेकिन अंत में यह गहरे बदलाव करना मुश्किल बना सकता है
    • Wayland की अहम बात यह है कि kernel उसके लिए बहुत-सा काम संभाल लेता है
      X वास्तव में दूसरे kernel की तरह काम करता था, जबकि Wayland kernel के GEM, DMA-BUF, KMS जैसे आधुनिक abstractions का लाभ उठाता है
      इसी वजह से यह कहीं ज़्यादा साफ़ और कुशल architecture की ओर बढ़ सकता है

  • मैं 10 साल से ज़्यादा समय से XFCE को मुख्य desktop के रूप में इस्तेमाल कर रहा हूँ
    Wayland support की खबर सुनकर खुशी हुई
    अगर यह Rust में लिखा जाता है, तो contributors को आकर्षित करने में भी मदद मिल सकती है
    अगर आप support करना चाहते हैं, तो Open Collective और xfce-eu पर donate करने की सलाह दूँगा

    • मैं 5 साल से XFCE इस्तेमाल कर रहा हूँ, और हाल ही में हर महीने support देना शुरू किया है। यह अच्छी खबर है, सुनकर खुशी हुई

  • मुझे लगता है X11 से Wayland की ओर बदलाव Linux इतिहास का सबसे पीड़ादायक परिवर्तन है

    • kernel 2.4 से 2.6 पर जाने का दौर भी काफ़ी कठिन था। development model पूरी तरह बदल गया था, और pre-git का समय बहुत अव्यवस्थित था
      KDE4 का दौर भी अंधकारमय था
    • व्यक्तिगत रूप से, मेरे लिए GNOME 2 → GNOME 3 का बदलाव सबसे कष्टदायक था। अंत में मैं किसी दूसरे WM पर चला गया
    • मेरे लिए X11 से Wayland का बदलाव बहुत सहज रहा। आखिरकार यह ज़रूरतों पर निर्भर करता है
    • 8 साल बाद शायद Wayland भी X11 जितना पुराना लगने लगे और Wayland 2 आ जाए
    • systemd migration भी कम मुश्किल नहीं था

  • मैंने Smithay का Rust client toolkit इस्तेमाल किया है, लेकिन इसकी thread safety पूरी नहीं लगती
    Arc<> में लिपटा होने पर भी multi-threaded calls के दौरान अजीब crashes आते हैं
    मैं Wayland API को सीधे समझकर इसे सुरक्षित तरीके से इस्तेमाल करना सीखना चाहता हूँ

  • अभी भी ज़्यादातर wlroots-आधारित compositors पर XFCE इस्तेमाल किया जा सकता है
    मैं Gentoo पर Hyprland + XFCE के संयोजन के साथ काम कर रहा हूँ
    configuration इस repository में है

    • retro theme अच्छा लगा
      Hyprland और XFCE4 के संयोजन को “शापित संयोजन” क्यों कहा गया, यह जानने की जिज्ञासा है। शायद इसका संबंध इस बात से है कि XFCE ने अपना compositor खुद बनाने का फैसला क्यों किया

  • एक समय मैं Wayland के खिलाफ था, लेकिन पुराने hardware पर performance देखकर मेरी राय बदल गई
    पुराने Thinkpad पर Firefox, X11 की तुलना में कहीं ज़्यादा smooth scroll करता है
    touchpad gestures भी मिल गए, जिससे संतोष है। setup थोड़ा झंझट वाला है, लेकिन यह क़ीमती trade-off है

  • क्या Wayland non-Linux systems पर भी काम करता है? जैसे BSD या macOS पर, क्या XQuartz की तरह remote windows दिखाना संभव है?

    • FreeBSD पर यह काफ़ी अच्छी तरह काम करता है। OpenBSD पर भी कुछ wlroots-आधारित compositors चलते हैं
      Mac के लिए Wayland compositor भी मौजूद है, और Brodie Robertson ने इस पर वीडियो डाला है
    • Microsoft का WSL2 GUI integration भी Wayland और XWayland पर आधारित है
      WSLg project देखें—यह Weston को RDP के जरिए render करता है, जिससे अलग-अलग platforms पर windows दिखाना संभव होता है
      GPU acceleration भी बनी रहती है, इसलिए यह X11 forwarding से बेहतर लगता है
    • Wayland में network transparency नहीं है, इसलिए remote transport जटिल है। Mac पर स्थिति क्या है, यह स्पष्ट नहीं है
    • FreeBSD की आधिकारिक handbook में भी Wayland setup का तरीका दिया गया है
      FreeBSD Handbook Wayland
    • OpenBSD पर भी Wayland_on_OpenBSD दस्तावेज़ के साथ प्रयोग चल रहे हैं

  • आजकल “Rust में rewrite” सुनने पर ऐसा लगता है जैसे maintainers नहीं बचे
    शायद xfwm4 को patch करने वाला कोई नहीं है, इसलिए इसे नए सिरे से लिखा जा रहा है
    यह पीढ़ीगत बदलाव का संकेत भी हो सकता है — नए developers इसे सरल और सुरक्षित architecture में फिर से बनाना चाहते हैं
    Wayland, X11 से सरल है, और Rust गलतियों को कम करता है, इसलिए यह स्वाभाविक दिशा लगती है
    लेकिन इसकी कीमत network transparency, performance, stability के रूप में चुकानी पड़ सकती है। समय का यही रुख है, इसलिए इसे स्वीकार करता हूँ