Term.everything - รันแอป GUI ทุกชนิดจากในเทอร์มินัล

 (github.com/mmulet)
55 คะแนน โดย GN⁺ 2025-09-11 | 9 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นโปรแกรม CLI สำหรับ Linux ที่ทำให้สามารถ รันแอปพลิเคชัน GUI ได้โดยตรงจากเทอร์มินัล
  • ใช้วิธีส่งเอาต์พุต GUI ไปยังเทอร์มินัลแทนจอภาพ ด้วย Wayland compositor ที่พัฒนาขึ้นเอง
  • สามารถใช้งานในสภาพแวดล้อม ssh ได้ และ รันเว็บเบราว์เซอร์, ตัวจัดการไฟล์, แม้กระทั่งเกม Doom ได้ภายในเทอร์มินัล
  • คุณภาพของเอาต์พุตจะแตกต่างตามความละเอียดของเทอร์มินัล (จำนวนแถว·คอลัมน์) และบนเทอร์มินัลที่รองรับภาพอย่าง iTerm2·kitty ก็รองรับ การเรนเดอร์แบบความละเอียดเต็ม ด้วย
  • พัฒนาด้วย Typescript และ bun พร้อมมีโค้ด C++ บางส่วน ปัจจุบันยังรองรับเฉพาะบางแอป แต่กำลังขยายต่อโดยมีเป้าหมาย “Term everything❗”

ความสำคัญของโปรเจกต์และจุดเด่นเมื่อเทียบกับทางเลือกอื่น

  • Term.everything แตกต่างจาก ตัวดูไฟล์ในเทอร์มินัล หรือเครื่องมือแสดงภาพแบบง่าย ๆ เดิม ๆ เพราะสามารถรันแอปพลิเคชัน GUI “ทุกอย่าง” ได้ภายในเทอร์มินัล
  • สามารถใช้อินเทอร์เฟซ GUI ได้แม้ในสภาพแวดล้อมเครือข่ายรวมถึง SSH จึงเด่นในด้าน การดูแลเซิร์ฟเวอร์และการพัฒนาระยะไกล
  • ใช้ประโยชน์จาก ความสามารถด้านภาพ ของเทอร์มินัลสมัยใหม่อย่าง kitty, iTerm2 ได้อย่างเต็มที่ พร้อมมีตัวเลือกเพิ่มความละเอียดและเฟรมเรต

ภาพรวม

  • Term.everything เป็นโปรแกรม Linux CLI ที่มีจุดเด่นคือทำให้สามารถรันหน้าต่าง GUI ได้โดยตรงในเทอร์มินัล
  • แกนหลักคือ Wayland compositor ที่พัฒนาขึ้นเอง ซึ่งเรนเดอร์ GUI ไปยังเทอร์มินัลแทนจอภาพทั่วไป
  • รองรับทั้ง x11 และ Wayland และยังใช้งานจากระยะไกลผ่าน ssh ได้
  • จำนวนแถว/คอลัมน์ที่จำกัดของเทอร์มินัลมีผลต่อคุณภาพของหน้าต่าง และสามารถเพิ่มคุณภาพได้ด้วยการเพิ่มความละเอียดของเทอร์มินัล (แต่อาจทำให้ประสิทธิภาพลดลง)

ตัวอย่างการใช้งานหลัก

  • รันเกม: สามารถรันเกมอย่าง Fontemon หรือ Doom (ตอน shareware) ภายในเทอร์มินัลได้
  • เล่นวิดีโอ: เล่นภาพยนตร์ Wing It! พร้อมปรับสมดุลระหว่างเฟรมเรตและคุณภาพภาพผ่านการตั้งค่าความละเอียด
  • รันเบราว์เซอร์: ใช้ Firefox ได้โดยเชื่อมต่อเข้า Ubuntu ผ่าน iTerm2 + ssh
  • ใช้แทนตัวดูไฟล์: ไม่จำเป็นต้องสร้างตัวดูไฟล์เฉพาะสำหรับเทอร์มินัล แต่ใช้ GUI file manager เดิมได้โดยตรงจากเทอร์มินัล
  • รันแบบซ้อน: รันเทอร์มินัลอีกตัวภายในเทอร์มินัล หรือ "terminal in a terminal"

หลักการทำงานและข้อมูลการพัฒนา

  • แนวคิดพื้นฐาน

    • ในอดีต หากโปรแกรมต้องการวาดบางอย่างบนหน้าจอ ก็สามารถ เขียนลงไปยังพื้นที่เฉพาะใน RAM โดยตรง ได้
    • ในระบบสมัยใหม่ Display Server จะเป็นผู้จัดการ I/O โดยประสานอินพุตอย่างเมาส์/คีย์บอร์ดกับเอาต์พุตกราฟิก/ภาพ
    • ในสภาพแวดล้อมลินุกซ์มักใช้ โปรโตคอล Wayland หรือ X11 และ Term.everything ทำงานบนพื้นฐานของ Wayland

  • โปรโตคอล Wayland

    • Wayland ไม่ใช่ตัว Display Server เอง แต่เป็นโปรโตคอลที่กำหนดการสื่อสารระหว่างเซิร์ฟเวอร์กับโปรแกรม
    • โปรแกรมจะส่งผลลัพธ์ที่เรนเดอร์เองไปยัง Display Server และเซิร์ฟเวอร์จะนำไปแสดงบนหน้าจอ
    • จุดสำคัญคือ ไม่ได้บังคับโมเดลการเรนเดอร์ → โปรแกรมจึงวาดภาพได้ในวิธีที่ต้องการ
    • ด้วยเหตุนี้ จึงสามารถส่งผลลัพธ์ไปยังที่อื่นแทนหน้าจอได้ (เช่น เทอร์มินัล)

  • การประมวลผลเอาต์พุตของ Term.everything

    • รับภาพที่ Wayland client (แอป GUI ที่รันอยู่) วาดขึ้นมา แล้ว แปลงเป็นเอาต์พุตตัวอักษรของเทอร์มินัล
    • ขั้นตอนการแปลง:
      • 1. รับข้อมูลภาพที่ client ส่งมา
      • 2. แปลงเป็น อักขระ UTF-8 + ANSI escape code
      • 3. ใช้ ไลบรารี chafa ในการแมปพิกเซลให้เป็นตัวอักษรในเทอร์มินัล
    • อินพุตจะถูกส่งผ่าน stdin และส่งต่อเหตุการณ์คีย์บอร์ดกับเมาส์ไปยัง Wayland client

  • การติดตั้งใช้งานจริง

    • ไอเดียหลักนั้นเรียบง่าย แต่การทำให้ใช้งานได้จริงต้องใช้โค้ดราว หนึ่งหมื่นบรรทัด
    • เขียนด้วย Typescript (บน bun) และ C++ บางส่วน โดยทำหน้าที่เป็น Wayland display server แบบคัสตอม
    • สามารถดูซอร์สโค้ดได้ที่ src/ directory

  • ความเป็นไปได้ในการขยายต่อ

    • Term.everything ไม่ได้มุ่งเพียงแค่การรัน GUI บนเทอร์มินัลเท่านั้น
    • ด้วย Wayland display server แบบคัสตอม จึงมีความเป็นไปได้ที่จะนำไปใช้ทำ ไอเดียเชิงทดลองอื่น ๆ ได้อีก
    • เช่น เชื่อมอุปกรณ์แสดงผลไปยังสื่อที่ไม่ใช่เทอร์มินัลโดยสิ้นเชิง (เช่น เครื่องพิมพ์, งานศิลปะเชิงกายภาพ เป็นต้น)

บทความที่เกี่ยวข้อง

9 ความคิดเห็น

 
iolothebard 2025-09-14

ซ้อนเกินจำเป็น
 
ifmkl 2025-09-11

แบบนี้แหละถึงจะ geek ของจริง 555
 
hybridego 2025-09-11

ทำไมของผมขึ้นแค่โลโก้แล้วใช้งานไม่ได้ครับ??
 
bus710 2025-09-11

ผมเคยใช้ Synergy เพื่อควบคุม Mac ส่วนตัวจาก Mac ของบริษัท แต่ตอนนี้ผมขาย Mac ส่วนตัวไปแล้วและใช้แต่ Linux อย่างเดียว เวิร์กโฟลว์เลยยุ่งยากขึ้น

แต่ถ้าใช้เครื่องมือนี้ ก็แปลว่าผมสามารถเชื่อมต่อจากเทอร์มินัลบน Mac ของบริษัทไปยังเดสก์ท็อป Linux ส่วนตัว แล้วทำงานโน่นนี่ได้ตามสะดวกเลยใช่ไหม?

ยังไงก็ตาม ดูเหมือนว่าทีมความปลอดภัยคงไม่ชอบแน่ ๆ
 
coremaker 2025-09-11

ผมเองก็คงเป็นสายเก๋าเหมือนกันล่ะมั้ง แต่สิ่งนี้จำเป็นด้วยเหรอ?
 
cgl00 2025-09-11

น่าจะมีประโยชน์เวลาใช้ทำการทดลองเกี่ยวกับเว็บบนเซิร์ฟเวอร์ (ผ่าน localhost)
 
coremaker 2025-09-11

หมายถึงกรณีที่อยากแก้ปัญหาบนเครื่อง локัลและทดสอบก่อน deploy ใช่ไหมครับ?
อย่างตอนที่ต้องทำงานจากระยะไกล หรืออยู่ในสภาพแวดล้อมที่มีข้อจำกัดเพราะเข้าถึงเครือข่ายภายในได้ยาก...
 
t7vonn 2025-09-11

ถ้าเปิด iTerm ภายใน iTerm ด้วย term.everything... จะได้ไหม?
 
GN⁺ 2025-09-11
ความคิดเห็นบน Hacker News
  • คิดว่าเป็นโปรเจกต์ที่ทั้งไร้ประโยชน์สุด ๆ และเท่มาก ๆ อยู่ตรงเส้นแบ่งระหว่างการเขียนโปรแกรมกับศิลปะ เชื่อว่านี่คงเป็นประสบการณ์การเรียนรู้ที่สนุกมากสำหรับโปรเจกต์นี้ อยากบอกว่าทำได้ยอดเยี่ยมจริง ๆ
    • ดูเหมือนจะไม่ได้ไร้ประโยชน์ไปซะทีเดียว 100% คิดว่าน่าจะมีประโยชน์กับแอปที่รันอยู่ใน Docker container ปกติก็มีวิธีเปิด GUI app ในคอนเทนเนอร์อยู่แล้ว แต่แบบนี้อาจจะง่ายกว่า ถึงอย่างนั้นการรัน GUI app บน Docker ก็ง่ายกว่าที่คิด ว่าจะลองทดสอบพรุ่งนี้โดยอ้างอิงจากไกด์นี้ และก็สงสัยว่าจะใช้บน Windows ได้ไหม
    • อธิบายยากว่าทำไมโปรเจกต์นี้ถึงทำให้ฉันมีความสุขขนาดนี้ แต่ถึงจะคิดว่าคงไม่ได้มีโอกาสใช้จริงบ่อยนัก แค่คิดถึงมันก็เผลอยิ้มโง่ ๆ ออกมา
  • นี่เป็นโปรเจกต์ที่ทำให้ไม่รู้เลยว่าขีดจำกัดอยู่ตรงไหน เท่มากและเป็นผลงานที่อยากอวดได้ไม่รู้จบ รู้สึกว่ามันสุดยอดมากจนทำให้กลับมาคิดว่าทีมควรจะทำ vdi ต่อไปยังไง ให้ความหมายใหม่กับคำว่า ghost in the shell เลยทีเดียว ว่าแต่จะรัน doom ได้ไหมนะ
    • ถ้าสงสัยก็ดูภาพ doom ตอนรันได้ term.everything รับอินพุตจาก stdin อย่างเดียว เลยต้องแก้ไม่กี่บรรทัดถึงจะให้มันทำงานได้ และมันเข้ากันได้ดีกับเทอร์มินัลหลายแบบผ่าน ssh
      1. แมปปุ่ม Control ไปเป็นปุ่มอื่นแทน (เดิมทีใช้ส่งสัญญาณ)
      2. ต้องปรับ input timeout การรับอินพุตแบบอิง stdin จะได้รับแค่ keydown event และจะไม่มี keyup event ดังนั้นจึงต้องเดาว่าผู้ใช้ปล่อยปุ่มตอนไหน ปกติส่ง keyup ทันทีเลยก็ได้ แต่ใน doom ต้องรอประมาณ 50~100ms เพราะมีการจัดการ key debounce ถ้าเป็นเกม ปกติแค่กดลูกศรขึ้นค้างไว้ก็เดินไปข้างหน้าได้ แต่ด้วยวิธีนี้ต้องกดซ้ำ ๆ เลยไม่ค่อยสะดวกนัก ถึงอย่างนั้นก็รันได้และเล่นได้จริง
    • aaquake เป็นเกมที่เคยรันในสภาพแวดล้อม ASCII terminal ได้มาก่อนโปรเจกต์แนวนี้แล้ว
  • คิดว่าโปรเจกต์นี้เจ๋งมาก ส่วนตัวคิดว่าน่าจะมี use case น่าสนใจแบบนี้บน Wayland เพิ่มอีกเยอะ และก็สนใจโปรเจกต์อย่าง greenfield ด้วย
  • ตอนก่อนหน้านี้ที่เคยเห็นโปรเจกต์ carbonyl รัน chromium ในเทอร์มินัลก็รู้สึกตื่นเต้นมาก(ดูที่นี่) แต่ตอนนี้มันไม่ได้รับการดูแลรักษาแล้ว โปรเจกต์นี้ให้ความรู้สึกเหมือนยกระดับไอเดียนั้นขึ้นไปอีกขั้น คิดจากใจเลยว่าเป็นผลงานที่เจ๋งมาก
  • คิดว่า bash_completion ควรถูกทำให้ใช้งานง่ายมาก ๆ แต่ความจริงคือเขียนยากกว่าที่คิด แม้แต่การคัดลอกวางตรง ๆ ยังยุ่งยาก นักพัฒนาที่ฉลาดจะสร้างแอปให้เข้ากับ bash_completion ได้ดีตั้งแต่แรก เช่น ถ้าอาร์กิวเมนต์หลักตัวแรกเป็นมิตรกับ bash โครงสร้างแบบ mycli myfunc ... ก็จะทำให้กดแท็บครั้งเดียวแล้วรู้ฟีเจอร์ทั้งหมดได้ทันที ฟีเจอร์ใหม่ก็ไม่ต้องคอยประกาศ แค่ไม่ใส่มันใน completion ก็เลิกใช้งานฟีเจอร์นั้นได้อย่างเป็นธรรมชาติโดยไม่ทำให้สคริปต์เดิมพัง สุดท้ายก็เหมือนมีคนจัดทุกอย่างไว้ใน CLI ให้แล้ว
  • สำหรับคนอย่างฉันที่บางครั้งต้องเข้าไปแตะเดสก์ท็อปหรือเบราว์เซอร์บน build machine โดยตรงเพื่อทำงาน VNC หรือการแชร์เดสก์ท็อปแบบอื่น ๆ มักไม่ค่อยใช้งานได้จริงหรือมีปัญหาด้านความปลอดภัย คิดว่าโปรเจกต์นี้น่าจะช่วยได้มากในสถานการณ์แบบนั้น
  • คิดว่าเป็นโปรเจกต์ที่ใช้งานได้จริงมาก เหมาะกับงานระยะไกลแบบครั้งคราว ไม่แน่ใจเรื่องการเชื่อมต่อเข้าไปยังโปรแกรมที่กำลังรันอยู่จากระยะไกลแล้วแยกออกมาอีกที หรือเรื่องการ mirror หน้าจอ แต่ถ้าสามารถ ssh เข้าเดสก์ท็อปแล้วควบคุมไคลเอนต์ที่กำลังเปิดอยู่ เช่น Discord ได้ก็น่าจะสะดวกดี อ้อ แล้วก็อยากลองดูฟีเจอร์ RDP ที่เกี่ยวกับการรันแอประยะไกลด้วย
    • จะใช้ไคลเอนต์ Discord สำหรับ CLI ไปเลยก็ได้ หรือไม่ก็รัน IRC client ที่เชื่อมกับเซิร์ฟเวอร์ Bitlbee
  • ต้องจดไว้ว่าเป็น <i>ในเทอร์มินัล</i> เตือนตัวเองไว้ว่านี่คงใช้ไม่ได้ใน text mode
    • แต่ตัวอย่างแรก (ตัวอย่างการ์ตูน) ไม่ใช่ text mode เหรอ
  • ขอให้โปรเจกต์นี้พัฒนาต่อไปเรื่อย ๆ อย่าหยุดเด็ดขาด
  • คิดว่าสุดยอดมากจริง ๆ! แต่ละคนน่าจะมี use case เฉพาะตัวต่างกันไป สำหรับฉันคาดหวังว่าจะเอา VSCode ไปรันบน iPad ได้ หวังว่าสักวันหนึ่งอาจรองรับ iPadOS ด้วย
    • ปกติฉันใช้ code-server สำหรับ remote development แล้วก็รู้สึกว่าเพียงพอ
    • มี ssh client บน iPad อยู่แล้ว คิดว่าน่าจะทำได้ กำลังจะลองเดี๋ยวนี้เลย