TUI फिर से क्यों लौट आया है

 (wiki.alcidesfonseca.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • TUI को उसकी तुरंत मिलने वाली feedback, automation में आसानी, और अलग-अलग operating systems पर चलने की क्षमता की वजह से फिर से ध्यान मिल रहा है; Claude और Codex जैसे tools ने भी command line पर बड़ी सफलता पाई है
  • Windows, Linux, macOS के native GUI अपने-अपने अस्थिर API strategy, toolkit और environment के बिखराव, और पुराने guidelines के साथ कमज़ोर होती consistency की वजह से developers और users दोनों पर बोझ बढ़ाते हैं
  • Electron apps में memory usage से बड़ा मुद्दा visual consistency की कमी और keyboard-centric workflow में मौजूद खालीपन है; menu और shortcut integration भी कमज़ोर हो गई है
  • Google के Flutter UI प्रयास और Zed के GPUI जैसी नई UI stack बनाने की कोशिशें हुईं, लेकिन अगर operating system integration कमज़ोर हो तो सिर्फ तेज renderer काफ़ी नहीं होता
  • अच्छी interface की कुंजी consistency है, जो users को कम सोचने पर मजबूर करती है; developers और operating system/toolkit बनाने वालों को UI theory और अधिक सुलभ toolkits में ज़्यादा निवेश करना चाहिए

TUI पर फिर से ध्यान क्यों जा रहा है

  • DHH का Omarchy एक मिश्रित रूप में बना है, जिसमें TUI, web apps, और gnome शैली के native apps शामिल हैं; TUI का इस्तेमाल तुरंत feedback और “geek points” के लिए होता है
  • लगभग 10 साल पहले code editors में भी ऐसा ही रुझान था
    • BBEdit, Textmate, Notepad++, Sublime जैसे native editors से Atom, VSCode और उनके derivative apps जैसे Electron-आधारित apps की ओर बदलाव हुआ
    • जिन users की पसंद बहुत मज़बूत थी, वे vim या emacs की ओर चले गए; वहाँ उन्हें तुरंत feedback और ऊँची usability मिली, लेकिन बदले में बहुत कठिन learning curve स्वीकार करनी पड़ी

Native GUI कमज़ोर क्यों हुए

  • Windows

    • Windows एक consistent GUI library strategy बना नहीं पाया, और अगर एक API सफल नहीं हुई तो दूसरी API बनाने का क्रम बार-बार दोहराता रहा
    • Jeffrey Snover ने Microsoft hasn’t had a coherent GUI strategy since Petzold में लिखा कि MFC, OLE, COM, ActiveX ने पूरे Windows development में complexity फैला दी
    • इसके बाद Microsoft ने WinForms, WPF, Silverlight, WinUI, MAUI तक का सफर किया, लेकिन सफलता नहीं मिली; कई enterprise और consumer desktop apps आज भी Electron apps पर निर्भर हैं
    • पूरे Windows के visually consistent होकर integrated दिखने का आख़िरी दौर Windows 98 या Windows 2000 के करीब था
    • Domenic Denicola ने Windows Native App Development Is a Mess में तर्क दिया कि हर कुछ साल में OS और UI API को फिर से बनाने की कीमत बहुत ज़्यादा है, और sandboxing तथा feature deprecation की कोशिशों के साथ हर नई layer में ऐसे gaps बन जाते हैं जिनमें पहले frameworks से संभव काम अब नहीं हो पाते

  • Linux

    • Linux में UI inconsistency लगभग design का ही नतीजा है, जहाँ अलग-अलग teams को अलग-अलग goals का पीछा करने की आज़ादी रही
    • GTK और Qt प्रमुख frameworks बने, और दोनों ने cross-platform native development का लक्ष्य रखा, लेकिन इनका सबसे व्यापक उपयोग मुख्यतः Linux में ही है
    • अलग-अलग toolkits से बने Linux apps को साथ रखो तो वे कुछ हद तक ठीक दिख सकते हैं, लेकिन Windows के कई frameworks उस स्तर की harmony नहीं बना पाते
    • distributions, desktop environments, और hardware combinations बहुत ज़्यादा होने से testing कठिन है, इसलिए कई कंपनियाँ native Linux apps बनाती ही नहीं हैं
    • कंपनियाँ आमतौर पर Linux support के लिए Electron का सहारा लेती हैं, या फिर public API होने पर open source community को इसे खुद सुलझाने देती हैं

  • macOS

Electron apps की सीमाएँ

  • सबसे ज़्यादा उठाया जाने वाला मुद्दा memory usage है, लेकिन पिछले 10 सालों में memory usage घटने की ओर ही रुझान रहा है
  • इससे बड़ा मुद्दा visual consistency की कमी और keyboard-centric workflow का अभाव है
  • 64GB RAM वाले MacBook Pro के environment में भी Dock पर 8 native apps और 6 Electron apps साथ मौजूद हैं
    • Native apps: TextMate और macOS system utilities
    • Electron apps: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
  • Cursor और VSCode जैसे apps में agent panel में कोई feature माँगने के बाद सिर्फ keyboard से side panel की agent list तक जाना या उसे archive करना स्वाभाविक नहीं लगता
  • ऐसे actions ideally हर macOS app में एक ही तरीके से संभव होने चाहिए, लेकिन shortcut होने पर भी कई बार वे menu में दिखाई नहीं देते
  • पिछले 10 सालों में developers में यह प्रवृत्ति बढ़ी है कि app में संभव actions को menu में जोड़ना भूल जाते हैं; यह उस संरचना से जुड़ा है जिसमें applications sandbox के अंदर HTML के रूप में implement होती हैं
  • Slack इस मामले को दूसरे Electron apps की तुलना में बेहतर संभालता है, लेकिन वह भी पूरी तरह सही नहीं है

नई UI stack फिर से बनाने की कोशिशें

  • Google, Dart के साथ Android की legacy से मुक्त एक नए operating system और नए devices के लिए UI toolkit बनाना चाहता था
  • Google को Flutter UI नाम का एक नया UI toolkit चाहिए था, लेकिन असली product launch होने से पहले ही उसने project छोड़ दिया
  • ऐसी कोशिशें तभी सफल हो सकती हैं जब आपके पास monopolistic position या बहुत बड़ा market share हो
  • Zed ने Rust के साथ इसी तरह का रास्ता चुना और अपना GPU renderer library GPUI बनाया, जो cross-platform होने का लक्ष्य रखता है
  • GPUI तेज़ है, लेकिन host operating system के साथ इसका integration अपने आप में पर्याप्त नहीं है, इसलिए developers को ज़रूरी bindings खुद जोड़नी पड़ती हैं
  • तेज renderer से बेहतर वह धीमा renderer है जो operating system के साथ अच्छी तरह integrate हो

TUI किस खालीपन को भर रहा है

  • Apple Automator के पतन की याद दिलाने वाले संदर्भ में, TUI automation-friendly interface के रूप में फिर महत्वपूर्ण हो गया है
  • TUI को remotely चलाना भी काफ़ी आसान है, और इसके लिए सिरदर्द पैदा करने वाले X forwarding पर निर्भर रहने की ज़रूरत नहीं पड़ती
  • जब native UI toolkits असफल होते हैं, तो चीज़ें फिर basics पर लौटती हैं, और उसी का नतीजा है कि TUI एक विकल्प के रूप में उभरता है
  • Claude और Codex ने command line पर बड़ी सफलता हासिल की है, और users आसपास के operating system की चिंता करने के बजाय interaction पर ध्यान दे सकते हैं
  • TUI के ज़रिए cloud machines पर code और apps को संभाला जा सकता है, या iPad से GPU-सक्षम machine पर remote access लिया जा सकता है
  • TUI उस खालीपन को भर रहा है जो Apple और Microsoft ने ऐसी दुनिया में छोड़ा है जहाँ हर application अलग दिखती है
  • अलग-अलग रूप कला या computer games के लिए अच्छे हो सकते हैं, लेकिन उस उद्देश्य के लिए उपयुक्त नहीं हैं जहाँ interface को पीछे हटकर user को अपना काम करने देना चाहिए

आगे किस दिशा की ज़रूरत है

  • John Loeber ने Bring Back Idiomatic Design में कहा कि checkbox भी system के साथ interact करने का interface है, और अच्छी interface वह है जो users को कम सोचने दे
  • users बहुत-सी चीज़ों के साथ interact करते हैं, इसलिए उन्हें consistent experience देने वाला homogeneous interface चाहिए
  • अगर Command+C copy shortcut है, तो उसे हर जगह काम करना चाहिए; ऐसा तरीका जिसमें किसी खास स्थिति में CTRL+Shift+C या right-click → copy अलग से याद रखना पड़े, असुविधाजनक है
  • हर developer को सिर्फ software ही नहीं, बल्कि अच्छे general user interface बनाने की theory भी सीखनी चाहिए
  • user design को software engineering curriculum में महत्वहीन soft skill की तरह देखने का रवैया बंद होना चाहिए
  • किसी भी process में अगर UI समझ में नहीं आता, तो project को असफल माना जाना चाहिए; HCI courses में लक्ष्य perfect UI होना चाहिए
  • अच्छी UI बनाने में ज़्यादातर मेहनत ज़रूरतों को समझने में लगती है; programming खुद तो पहले ही automate हो रही है
  • operating systems और toolkits बनाने वालों को ऐसे अधिक सुलभ toolkits बनाने और entry barrier घटाने में निवेश बढ़ाना चाहिए जिन्हें developers इस्तेमाल करना चाहें
  • यह ज़रूरी नहीं कि cross-platform support पर ही ज़ोर दिया जाए, लेकिन अगर ऐसा कोई एक समाधान भी हो तो वह Electron और TUI पर निर्भरता कम करने में मदद कर सकता है

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

2 टिप्पणियां

 
colus001 45 분 전

मुझे भी ऐसा ही लगता है, लेकिन मेरा मानना है कि dev scene ज़रूरत से ज़्यादा trends के प्रति संवेदनशील है। TUI को बस वे कंपनियाँ आगे बढ़ा रही हैं जिनके पास GUI को ठीक से बनाने की क्षमता या इच्छा नहीं है; पता नहीं वास्तव में कितने लोग TUI का इस्तेमाल कर रहे हैं।
 
GN⁺ 2 시간 전
Lobste.rs की रायें

  • अच्छा होता अगर लोग native apps ही बनाते। TUI मुझे command-line interface और असली GUI — दोनों की कमियों का मिला-जुला रूप लगता है
    हर TUI प्रोग्राम को scrolling खुद दोबारा implement करनी पड़ती है, इसलिए terminal pixel-level scrolling support करता हो तब भी TUI programs अक्सर सिर्फ line-by-line scrolling देते हैं, और उनका व्यवहार भी अलग-अलग होता है। senpai का scrollback मेरे बाकी programs से अलग चलता है, इसलिए मैं बार-बार गड़बड़ा जाता हूँ
    Terminal को यह बताने का कोई तरीका भी नहीं होता कि interface सिर्फ एक text panel से ज़्यादा है, इसलिए text selection अक्सर टूट जाती है। Mouse events को hijack करके यह किया जा सकता है, लेकिन वह भी अपने आप में खास अच्छा नहीं है। एक TUI IRC client में text select करने के लिए मुझे बाएँ-दाएँ के बेकार panels छिपाने वाला shortcut दबाना पड़ता था, और यह काफ़ी बेवकूफ़ी भरी प्रक्रिया थी
    Grid के हिसाब से चलने की बाध्यता layout और design की संभावनाओं को बहुत सीमित कर देती है। जैसे clickable buttons जैसा styling, या context menu जैसी चीज़ें। मैंने पहले भी इस समस्या पर शिकायत की थी
    मुझे लगता है TUI का बढ़ना इस दुखद स्थिति का नतीजा है कि पारंपरिक GUI frameworks की हालत अच्छी नहीं है। TUI frameworks तुलनात्मक रूप से स्थिर हैं, और बहुत पुराने वाले भी इस्तेमाल करो तो ज़्यादा खटकते नहीं। ncurses programs आज भी अक्सर इस्तेमाल होते हैं, लेकिन Motif programs इस्तेमाल होते हुए कल्पना करना मुश्किल है
    दूसरी ओर GUI frameworks के विकल्प ज़्यादा नहीं हैं और उन्हें maintain भी कहीं अधिक करना पड़ता है। Desktop environments बदलते रहते हैं, और GUI से लोगों की अपेक्षाएँ भी बढ़ती रहती हैं। TUI accessibility मुझे सच में बहुत खराब लगती है, हालाँकि मैं पूरे यक़ीन से नहीं कह सकता। बदलाव भी इतने आते रहते हैं कि GTK2 में बनाया तो deprecated, GTK3 पर गए तो अब GTK4 पर जाओ — ऐसा सिलसिला चलता रहता है
    थोड़ा निंदक होकर देखें तो Omarchy जैसी चीज़ों के पीछे और भी कारण हैं। साधारण GUI xfce4-taskmanager उबाऊ दिखता है, लेकिन TUI btop बहुत hacker-जैसा दिखता है। लोगों को terminal aesthetics पसंद हैं (/r/unixporn देखें), और वे vibe के लिए usability की क़ुर्बानी देने को भी तैयार लगते हैं। btop सचमुच process list को fade out करता है, यह देखकर यही लगता है

    • लंबे समय तक web development करने के बाद मैं native application development आज़माना चाहता था। GNOME app बनाने के लिए देखा, लेकिन उसका C++-केंद्रित होना काफ़ी निराशाजनक लगा
      मुझे उम्मीद थी कि अब तक entry barrier कम हो चुका होगा। जब ज़्यादातर developers high-level languages में प्रशिक्षित होते हैं, तब यह ज़्यादा समझदारी भरा नहीं लगता, और शायद C++ की complexity ही मुझे डरा देती है
    • बात अलग है, लेकिन समझ नहीं आता कि इतने सारे chat clients chat history को copy-paste करने पर formatting क्यों बिगाड़ देते हैं। उदाहरण के लिए Discord में यह कुछ ऐसा निकलता है
      [
      20:41
      ]
      username1
      :
      message1
      [
      20:42
      ]
      username2
      :
      message2
      Matrix client Nheko तो एक बार में एक से ज़्यादा line select भी नहीं करने देता
      जबकि IRC clients by default यह रूप देते हैं
      20:41 <username1> message1
      20:42 <username2> message2
    • मुझे command-line interfaces पसंद हैं, लेकिन TUI मुझे भी खास पसंद नहीं। इनके उपयोग हैं, पर असल में ये खुरदरे और बदसूरत GUI के काफ़ी करीब हैं, और कई बार terminal space भी बर्बाद करते हैं
      कभी-कभी ये ठीक लगते हैं, लेकिन आदर्श रूप से इन्हें छोटे, थोड़ी देर के लिए इस्तेमाल होने वाले apps या text editing जैसी exceptions तक सीमित रहना चाहिए
    • मुझे भी TUI कुछ कमज़ोर लगते हैं, लेकिन gtk जैसी UI toolkits की तुलना में यह फिर भी कम बुरा विकल्प है। जो TUI apps मुझे पसंद हैं वे extensible हैं, तेज़ हैं, और Linux command line के साथ अच्छी तरह integrate होते हैं
      जैसे lf, tig, kakoune shell scripts के साथ अच्छी तरह मेल खाते हैं, इसलिए वही scripts दोबारा इस्तेमाल की जा सकती हैं और तीनों apps में features बढ़ाए जा सकते हैं। ये तीनों alacritty में चलते हैं, इसलिए मैं ऐसे hyperlinks भी बना सकता हूँ जो इन तीनों apps और पूरे shell environment में काम करें
      अगर सपने देखूँ, तो मैं ऐसी monochrome minimalist GUI toolkit चाहूँगा जो Emacs या acme-style integration की अनुमति दे
    • मैं कुल मिलाकर सहमत हूँ, लेकिन यह ज़रूर कहना चाहूँगा कि Tk चुपचाप चलता रहा है और आज भी उपयोगी है। gitk इसका उदाहरण है

  • मुझे समझ नहीं आता कि TUI को “automation-friendly” कैसे कहा जा रहा है। क्या यह बस console में दिखने वाला GUI नहीं है?

    • कई TUI programs start होते समय ऐसे flags देते हैं जो scripting language की तरह काम करते हैं। और LLM के लिए भी सही native GUI या JavaScript-झुकाव वाले Electron app की तुलना में text-based interface के साथ interact करना आसान और सस्ता पड़ता है

  • इस लेख ने TUI के “वापस आने” की सबसे अहम वजह छोड़ दी। खुद यह दावा भी संदिग्ध है, लेकिन Claude जैसे coding agents के ज़रिए बड़े पैमाने पर vibe coding होने से हाल में इसकी लोकप्रियता बढ़ी है, यह सही लगता है
    Developers आसान रास्ता पसंद करते हैं। cross-platform TUI बनाना GUI बनाने से आसान है
    Web apps के लोकप्रिय होने की वजह भी यही थी। Browser tools से cross-platform apps बनाना आसान था, और Electron के उभरने के पीछे भी लगभग यही कारण था, बस cross-browser support का बोझ हट गया। Responsive UI बनाना, UI को cross-platform तरीके से render करना, और user input को, खासकर accessibility को ध्यान में रखकर, संभालना — ये सब मुश्किल काम हैं। इसलिए developers तुरंत ऐसी किसी चीज़ पर कूद पड़ते हैं जो यह आसान बना दे
    हाल में TUI बनाना आसान करने वाले कुछ बदलाव भी आए हैं। Advanced features के cross-platform support में सुधार हुआ है, और ऐसी लोकप्रिय libraries आई हैं जो जटिल बारीकियों को abstract कर देती हैं। शायद इन्हीं चीज़ों ने हाल की TUI renaissance को जन्म दिया है
    इसके अलावा लेख के कुछ तर्क संदिग्ध लगते हैं। उदाहरण के लिए लेखक Electron apps की कमी के रूप में consistency का ज़िक्र करता है, लेकिन लोकप्रिय TUI में भी conventions को छोड़ दें तो consistency लगभग नहीं के बराबर है। Coding agents ने मिलते-जुलते shortcuts अपनाए हैं, पर ज़्यादातर ने एक ही स्रोत Claude की नकल की है। वे shortcuts coding agents के बाहर ज़्यादा काम नहीं आते, और जिन अधिकांश TUI का मैं इस्तेमाल करता हूँ, उनके shortcuts और visual language काफ़ी अलग हैं

    • “Responsive UI बनाना मुश्किल है” से आपका मतलब क्या है, यह समझ नहीं आता। यह web की बात जैसा लगता है; web के कुछ ideas यहाँ प्रासंगिक हो सकते हैं, लेकिन native GUI की चर्चा में यह थोड़ा off-topic लगता है। क्या मतलब बस “अच्छा UI बनाना” या “UI toolkit बनाना” था?
      “UI को cross-platform तरीके से render करना मुश्किल है” यह भी कुछ अजीब लगता है। Compatibility layer चाहिए और जितने platforms हों उतने implementations भी, लेकिन single-platform support से यह इतना ज़्यादा मुश्किल नहीं लगता। हाँ, अगर target platforms की rendering styles इतनी अलग हों कि common API बनाना कठिन हो, तो बात अलग है, लेकिन screen पर pixels डालने के स्तर पर ऐसा नहीं होना चाहिए। Scaling जैसी चीज़ें संभालनी पड़ेंगी, लेकिन उसके आगे यह काफ़ी सीधा होना चाहिए, और नहीं तो SDL है ही
      शायद आपका मतलब हर platform पर UI को “native जैसा दिखाना” था। उसके लिए हर platform की पसंदीदा native GUI toolkit इस्तेमाल करनी पड़ सकती है, और वे न सिर्फ़ बहुत अलग हैं बल्कि low-level rendering API की तुलना में कहीं बड़ी और कम स्थिर भी हो सकती हैं। उसके लिए ज़िंदगी बहुत छोटी है। मैं रंग theme या graphic style के कुछ हिस्से बदलने की गुंजाइश दूँगा, लेकिन उसे app-level setting ही रखूँगा। हर OS की graphics settings पढ़ने में समय बर्बाद नहीं करना चाहता
      “User input, खासकर accessibility को संभालना मुश्किल है” यह भी अजीब लगता है। Keyboard और mouse events सुनना बहुत मामूली काम है। Accessibility के लिहाज़ से सही keyboard navigation ज़रूरी है, और overall usability के लिए भी महत्त्वपूर्ण है; standard और custom shortcuts का support भी चाहिए, लेकिन कुल मिलाकर यह बाकी सब चीज़ों से कहीं आसान लगता है
      Screen reader support संबंधित platform API और platforms के बीच differences के कारण मुश्किल हो सकता है, लेकिन वह input से ज़्यादा rendering की समस्या के करीब है

  • TUI का “comeback” कम और native GUI programming knowledge खो देने के बाद उपलब्ध tools से काम चलाने जैसा ज़्यादा है। यह लगातार development और investment की कमी का नतीजा है
    Qt जैसी कुछ चमकीली exceptions को छोड़ दें तो UI civilization ढह चुकी है और हम किसी post-apocalyptic दौर में जी रहे हैं
    यह Preventing the Collapse of Civilization वाली talk के साथ तुक मिलाता सा लगता है, और अब जब AI बहुत-सा code लिख रहा है, तो डर है कि यह knowledge collapse और न फैल जाए

    • lobste.rs पर जब-जब यह विषय आता है, मैं बीच में कूद पड़ता हूँ, तो यहाँ भी कूदना बनता है। हर GUI “empire” हमारी आँखों के सामने गिर रहा है। Windows, macOS, GTK, Mozilla products — सब
      लगता है जैसे computer science की दुनिया को After Virtue जैसी किसी चीज़ की ज़रूरत है, और शायद Blow की online मौजूदगी थोड़ा-बहुत वही भूमिका निभा रही है। खैर, मुझे वह दौर याद आता है जब computer interfaces consistency दिखाते थे, user का सम्मान करते थे, और सीखने व मेहनत का इनाम देते थे

  • इस लेख में ठोस बात बहुत कम है; बस इतना लगता है कि लेखक को बाकी सब कुछ बेकार लगता है
    अगर एक बात कहनी हो, तो Emacs text, keyboard, buttons, और rich media interfaces के लिए एक शानदार platform है

  • शायद इसलिए कि लोग Go, Rust, और अब Zig में ncurses की जगह TUI libraries इस्तेमाल करने लगे हैं। फिर भी उन्होंने उन भयानक portability problems को हल कर दिया जिनके कारण ncurses की ज़रूरत पड़ती थी
    उसके बाद लोगों ने नए terminals बनाना शुरू किया और उस तरफ़ की technology को भी आगे बढ़ाया। आंशिक कारण यह है कि अब यह सब C की जगह Go, Rust, Zig में बनाया जा सकता है
    जब आप C और C++ से ज़्यादा मज़ेदार और कम परेशान करने वाले अच्छे विकल्प देते हैं, तो लोग स्वाभाविक रूप से नया और उपयोगी code लिखना शुरू कर देते हैं

  • TUI के वापस आने की असली वजह यह है कि 2026 में signed और notarized GUI distribute करने के लिए Apple को पैसे देने पड़ते हैं, और Windows के लिए certificate authority को भी पैसे देने पड़ते हैं

    • क्या native TUI binary के साथ भी वही समस्या नहीं है?

  • एक छोटी technical correction: Zed की GPU-accelerated UI library cross-platform API wgpu नहीं, बल्कि gpui है

  • पक्का नहीं कि लेख ने अपनी बात ठीक से साबित की या नहीं, लेकिन MS-DOS era से गुज़रा हूँ और हमेशा TUI पसंद रहा है, इसलिए मैं भी कुछ कहूँगा। अगर आपने afl-fuzz इस्तेमाल किया है, तो शायद समझेंगे
    सिद्धांततः Linux पर TUI को कहीं ज़्यादा सफल होना चाहिए था। वहाँ text-based aesthetics पसंद करने वाला technical user base था, और खुरदरे, inconsistent GUI environments का “फ़ायदा” भी था। वह समय भी था जब video card को X server में सही तरह चलाना ही एक समस्या होता था
    साथ ही, दशकों तक *nix software developers खुद को इस बात के लिए बाध्य महसूस करते रहे कि उन्हें पुराने और विचित्र terminal types तक support देना है। अगर application DECwriter पर ठीक से render न हो तो मानो कोई आपदा आ जाएगी — ऐसी मानसिकता थी, और उन constraints के भीतर अच्छा TUI बनाना मुश्किल था
    MS-DOS के दौर में Microsoft, Borland, Norton जैसी कंपनियों ने functional और responsive text-based interfaces को काफ़ी निखार लिया था। Linux में लंबे समय तक TUI design की “चोटी” menuconfig जैसा एक राक्षसी example था, और अगर बहुत आँखें मिचमिचाएँ तो vim को भी TUI कह सकते हैं। जब लोग सचमुच text-mode console इस्तेमाल करते थे, उस दौर का मुझे याद रहने वाला अच्छा Linux TUI शायद सिर्फ़ Norton Commander से प्रेरित file manager Midnight Commander है