Term.everything - टर्मिनल में सभी GUI ऐप चलाना

 (github.com/mmulet)
55 पॉइंट द्वारा GN⁺ 2025-09-11 | 9 टिप्पणियां | WhatsApp पर शेयर करें
  • Linux के लिए एक CLI प्रोग्राम, जो GUI एप्लिकेशन को सीधे टर्मिनल में चलाने देता है
  • यह अपने खुद के Wayland compositor का उपयोग करता है, जो मॉनिटर की जगह GUI आउटपुट को टर्मिनल तक पहुंचाता है
  • ssh वातावरण में भी चल सकता है, और वेब ब्राउज़र, फ़ाइल मैनेजर, यहाँ तक कि Doom गेम भी टर्मिनल के भीतर चला सकता है
  • आउटपुट क्वालिटी टर्मिनल resolution (rows·columns की संख्या) पर निर्भर करती है, और iTerm2·kitty जैसे image-supporting terminals में full-resolution rendering भी सपोर्ट करता है
  • इसे Typescript और bun के आधार पर बनाया गया है, इसमें कुछ C++ कोड भी शामिल है, और फिलहाल यह कुछ ऐप्स तक सीमित है, लेकिन “Term everything❗” के लक्ष्य के साथ लगातार विस्तार हो रहा है

प्रोजेक्ट का महत्व और तुलनात्मक बढ़त

  • Term.everything पारंपरिक terminal file viewer या साधारण image output tools से अलग है, क्योंकि यह “सभी” GUI एप्लिकेशन को टर्मिनल के अंदर चला सकता है
  • SSH सहित नेटवर्क वातावरण में भी GUI इंटरफ़ेस इस्तेमाल किया जा सकता है, इसलिए server management, remote development में इसकी खास उपयोगिता है
  • यह kitty, iterm2 जैसे आधुनिक terminals की image capabilities का पूरा उपयोग करता है, और resolution·framerate बढ़ाने के विकल्प भी देता है

अवलोकन

  • Term.everything एक Linux CLI प्रोग्राम है, जिसकी खासियत यह है कि यह टर्मिनल में GUI विंडो को सीधे चलाने देता है
  • इसका मुख्य हिस्सा एक स्वयं विकसित Wayland-आधारित compositor है, जो सामान्य मॉनिटर की जगह टर्मिनल में GUI को render करता है
  • यह x11 और Wayland दोनों आधारित ऐप्स को सपोर्ट करता है, और ssh के माध्यम से remote उपयोग भी संभव है
  • टर्मिनल की सीमित rows/columns विंडो क्वालिटी को प्रभावित करती हैं, और टर्मिनल resolution बढ़ाने पर क्वालिटी बेहतर हो सकती है (हालांकि performance कम हो सकती है)

प्रमुख उपयोग उदाहरण

  • गेम चलाना: टर्मिनल के अंदर Fontemon जैसे गेम या Doom (shareware episode) चलाया जा सकता है
  • वीडियो चलाना: Wing It! फ़िल्म चलाई जा सकती है, और resolution समायोजित करके framerate तथा image quality के बीच संतुलन बनाया जा सकता है
  • ब्राउज़र चलाना: iTerm2 + ssh वातावरण में Ubuntu से कनेक्ट होकर Firefox चलाया जा सकता है
  • फ़ाइल व्यूअर का विकल्प: अलग से terminal-only file viewer बनाने की ज़रूरत नहीं, मौजूदा GUI file manager को सीधे टर्मिनल में इस्तेमाल किया जा सकता है
  • रिकर्सिव रनिंग: टर्मिनल के अंदर एक और टर्मिनल चलाना, यानी "terminal in a terminal"

कार्यविधि और विकास संबंधी जानकारी

  • बुनियादी अवधारणा

    • पहले के समय में, अगर किसी प्रोग्राम को स्क्रीन पर कुछ बनाना होता था, तो वह RAM के एक विशेष हिस्से में सीधे लिख सकता था
    • आधुनिक सिस्टम में Display Server इनपुट और आउटपुट को संभालता है, और माउस/कीबोर्ड जैसे इनपुट तथा graphics/image output का समन्वय करता है
    • Linux वातावरण में आम तौर पर Wayland protocol या X11 का उपयोग होता है, और Term.everything Wayland पर आधारित है

  • Wayland protocol

    • Wayland स्वयं display server नहीं है, बल्कि सर्वर और प्रोग्राम के बीच संचार को परिभाषित करने वाला एक protocol है
    • प्रोग्राम अपने द्वारा render किया गया परिणाम display server को देता है, और सर्वर उसे स्क्रीन पर दिखाता है
    • महत्वपूर्ण बात यह है कि यह कोई निश्चित rendering model थोपता नहीं है → प्रोग्राम अपनी इच्छानुसार चित्र बना सकता है
    • इसी वजह से आउटपुट को स्क्रीन की बजाय किसी और जगह (जैसे टर्मिनल) भेजना संभव है

  • Term.everything में आउटपुट प्रोसेसिंग

    • Wayland client (चल रहा GUI ऐप) द्वारा बनाई गई image को लेकर उसे टर्मिनल character output में बदला जाता है
    • रूपांतरण प्रक्रिया:
      • 1. client द्वारा भेजा गया image data प्राप्त करना
      • 2. उसे UTF-8 characters + ANSI escape codes में बदलना
      • 3. इस रूपांतरण में chafa library का उपयोग करके pixels को terminal characters से मैप करना
    • इनपुट के लिए stdin से आने वाले keyboard और mouse events को Wayland client तक पहुंचाया जाता है

  • वास्तविक इम्प्लीमेंटेशन

    • मूल विचार सरल है, लेकिन वास्तविक इम्प्लीमेंटेशन में लगभग दस हज़ार लाइनों के कोड की ज़रूरत पड़ी
    • यह Typescript (bun आधारित) और कुछ C++ में लिखा गया है, और custom Wayland display server की भूमिका निभाता है
    • source code को src/ directory में देखा जा सकता है

  • विस्तार की संभावना

    • Term.everything का लक्ष्य सिर्फ टर्मिनल में GUI चलाना भर नहीं है
    • Wayland-आधारित custom display server का उपयोग करके अन्य प्रयोगात्मक विचारों को भी लागू किया जा सकता है
    • उदाहरण: आउटपुट डिवाइस को टर्मिनल की बजाय किसी बिल्कुल अलग माध्यम (जैसे printer, physical artwork आदि) से जोड़ना

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

9 टिप्पणियां

 
iolothebard 2025-09-14

ऊपर पर ऊपर
 
ifmkl 2025-09-11

यही तो सच में geeky है ह
 
hybridego 2025-09-11

मेरे यहाँ सिर्फ़ लोगो ही दिख रहा है, यह चल क्यों नहीं रहा??
 
bus710 2025-09-11

मैं अपनी कंपनी के Mac से अपने निजी Mac को कंट्रोल करने के लिए Synergy इस्तेमाल करता था। अब मैंने अपना निजी Mac हटा दिया है और सिर्फ Linux इस्तेमाल करता हूँ, इसलिए workflow थोड़ा झंझटभरा हो गया है.

लेकिन अगर मैं यह tool इस्तेमाल करूँ, तो क्या इसका मतलब है कि मैं कंपनी के Mac के terminal से अपने निजी Linux desktop में connect होकर तरह-तरह के काम खुलकर कर सकता हूँ?

लगता है security team को यह बिल्कुल पसंद नहीं आएगा.
 
coremaker 2025-09-11

शायद मैं भी पुराना यूज़र हूँ, लेकिन क्या सच में इसकी ज़रूरत है?
 
cgl00 2025-09-11

यह सर्वर पर वेब-संबंधित प्रयोगों (लोकलहोस्ट के जरिए) के दौरान उपयोगी लग सकता है।
 
coremaker 2025-09-11

आपका मतलब है कि आप लोकल में समस्या हल करना और deploy से पहले test करना चाहते हैं, सही?
रिमोट लोकेशन पर काम करना, internal network access मुश्किल होना, और environment सीमित होना जैसी स्थितियों में...
 
t7vonn 2025-09-11

अगर iTerm के अंदर term.everything से iTerm खोलें.. तो क्या यह काम करेगा?
 
GN⁺ 2025-09-11
Hacker News राय
  • मुझे लगता है यह एक बिल्कुल बेकार होते हुए भी शानदार प्रोजेक्ट है, यह प्रोग्रामिंग और कला की सीमा पर खड़ा है, मुझे यक़ीन है कि यह प्रोजेक्ट एक बेहद मज़ेदार learning experience रहा होगा, बस कहना चाहता हूँ कि यह वाकई बहुत बढ़िया है
    • मुझे नहीं लगता कि यह 100% बेकार है, Docker container के अंदर चलने वाले apps के लिए यह उपयोगी हो सकता है, आम तौर पर container के अंदर GUI app चलाने के तरीके होते हैं, लेकिन यह शायद उससे आसान हो, हालांकि Docker में GUI app चलाना सोच से ज़्यादा आसान है, मैं कल इस गाइड को देखकर test करने वाला हूँ, और यह Windows पर भी काम करता है या नहीं यह जानने की जिज्ञासा है
    • यह समझाना मुश्किल है कि यह प्रोजेक्ट मुझे इतना खुश क्यों करता है, लेकिन भले ही शायद इसका इस्तेमाल कम ही हो, इसके बारे में सोचते ही चेहरे पर बेवकूफ़ी भरी मुस्कान आ जाती है
  • यह ऐसा प्रोजेक्ट है जो सीमाएँ कहाँ हैं, यह समझना मुश्किल बना देता है, सच में शानदार है और ऐसा नतीजा है जिस पर अनंत बार शेख़ी बघारने का मन करे, इसे देखकर मैं प्रभावित हूँ और हमारी team में यह सोचने पर मजबूर हूँ कि आगे VDI को कैसे implement करना चाहिए, यह "ghost in the shell" को जैसे एक नया मतलब देता है, वैसे क्या इसमें doom भी चल सकता है यह जानने की जिज्ञासा है
    • अगर जिज्ञासा है, तो doom चलते हुए देख सकते हैं, term.everything सिर्फ stdin से input लेता है इसलिए मैंने कुछ lines बदलकर इसे चलाया, ssh के ज़रिए अलग-अलग terminals में इसकी compatibility काफ़ी अच्छी है
      1. Control key को किसी दूसरी key पर map किया
      2. input timeout को adjust करना पड़ा. stdin-आधारित input में सिर्फ keydown event मिलते हैं, keyup event नहीं आते, इसलिए यह अंदाज़ा लगाना पड़ता है कि user ने किस समय key छोड़ी होगी. आम तौर पर तुरंत keyup भेजना ठीक रहता है, लेकिन doom में key debounce handling की वजह से लगभग 50~100ms इंतज़ार करना पड़ा. गेम में आगे बढ़ने के लिए आम तौर पर ऊपर वाला arrow key दबाकर रखा जाता है, लेकिन अभी के तरीके में उसे बार-बार दबाना पड़ता है, इसलिए थोड़ा असुविधाजनक है, फिर भी यह चल जाता है और खेला जा सकता है
    • aaquake ऐसा गेम है जो इस तरह के प्रोजेक्ट्स से पहले ही ASCII terminal environment में चल चुका था
  • मुझे लगता है यह प्रोजेक्ट सच में शानदार है, व्यक्तिगत रूप से मुझे लगता है कि Wayland आधारित ऐसे दिलचस्प use cases आगे और बढ़ेंगे, greenfield जैसे प्रोजेक्ट में भी मेरी रुचि है
  • पहले जब मैंने carbonyl प्रोजेक्ट में chromium को terminal में चलते देखा था तो मैं बहुत उत्साहित हो गया था (यहाँ देखें), लेकिन अभी उसका maintenance नहीं हो रहा, यह प्रोजेक्ट उस idea का एक step-up version लगता है, सच में कमाल का नतीजा है
  • मुझे लगता है कि bash_completion को सच में बहुत आसान बनाना चाहिए, हक़ीक़त में इसे लिखना उम्मीद से कठिन है, साधारण copy-paste भी झंझट भरा होता है, समझदार developers शुरू से ही ऐसे apps बनाते हैं जो bash_completion के साथ अच्छी तरह काम करें, उदाहरण के लिए अगर पहला मुख्य argument bash-friendly हो, तो सिर्फ mycli myfunc ... जैसी संरचना से tab key एक बार दबाते ही सारे features का पता चल सकता है, नई functionality के लिए अलग से प्रचार की ज़रूरत नहीं होती, और अगर किसी feature को completion से हटा दिया जाए तो पुराने scripts टूटे बिना उसे स्वाभाविक रूप से deprecated भी किया जा सकता है, आख़िरकार बात यह है कि किसी ने पहले से मेहनत की होती है, इसलिए सब कुछ CLI में समा जाता है
  • जब मेरी तरह किसी build machine पर कभी-कभी desktop या browser को सीधे access करके काम करना पड़ता है, तब VNC या दूसरे desktop-sharing तरीके practical नहीं होते या security concern पैदा करते हैं, मुझे लगता है यह प्रोजेक्ट ऐसी स्थितियों में बहुत मददगार होगा
  • मुझे लगता है यह सच में उपयोगी प्रोजेक्ट है, remote से one-off काम करने के लिए ठीक लग रहा है, चल रहे program से remote attach होकर फिर detach होना या screen mirroring वाला हिस्सा कितना अच्छा है यह पक्का नहीं, लेकिन अगर SSH से desktop में login करके पहले से चल रहे Discord जैसे client को control किया जा सके तो यह काफ़ी सुविधाजनक होगा, वैसे remote app execution से जुड़े RDP features भी देखना चाहूँगा
    • आप सीधे CLI के लिए Discord client इस्तेमाल कर सकते हैं, या Bitlbee server से connected IRC client चला सकते हैं
  • मुझे <i>terminal में</i> वाली बात नोट कर लेनी चाहिए, खुद को याद दिलाता हूँ कि यह शायद text mode में काम नहीं करेगा
    • लेकिन क्या पहला example (comic example) text mode नहीं था?
  • प्रोजेक्ट की लगातार प्रगति की कामना करता हूँ, उम्मीद है यह कभी रुके नहीं
  • मुझे यह सच में कमाल का लगता है! हर किसी के अपने अलग use cases होंगे, मेरे लिए सबसे रोमांचक संभावना iPad पर VSCode चलाने की है, उम्मीद है कि कभी iPadOS support भी आ सके
    • remote development के लिए मैं आम तौर पर code-server इस्तेमाल करता हूँ और वह मेरे लिए काफ़ी है
    • iPad के लिए ssh clients मौजूद हैं, इसलिए मुझे लगता है यह संभव है, मैं अभी तुरंत इसे आज़माने की योजना बना रहा हूँ