현대적인 TUI 프레임워크 구축에서 배운 7가지

 (textualize.io)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Textual 개발 과정은 오래된 터미널 프로토콜 위에서도 부드러운 TUI 애니메이션을 만들 수 있지만, 화면 갱신 방식과 출력 동기화를 세심하게 다뤄야 함
  • 깜빡임을 줄이려면 화면을 지우지 않고 덮어쓰고, 표준 출력에 한 번에 쓰며, Synchronized Output 프로토콜을 활용하는 방식이 중요함
  • Python의 dict.items() 뷰와 @lru_cache는 렌더 변경분 계산과 작은 고빈도 함수 최적화에 유용하며, CPython의 C 구현이 캐시 성능을 뒷받침함
  • 불변에 가까운 객체, Unicode 박스 문자 다이어그램, fractions.Fraction은 각각 추론·캐싱·테스트, 문서 이해, 레이아웃 계산의 정확성을 높임
  • 터미널 Emoji는 Unicode 버전, 문자 폭, 다중 코드포인트 렌더링 차이 때문에 예측하기 어려워, 실무에서는 Unicode 9 수준의 단순한 Emoji가 더 안정적임

터미널 애니메이션과 깜빡임 제어

  • 현대 터미널 에뮬레이터는 오래된 프로토콜 위에서 동작하지만, 많은 구현이 비디오 게임에도 쓰이는 그래픽 기술을 사용함
  • 터미널 시각 효과는 깜빡임이나 tearing이 생기기 쉽지만, 몇 가지 조건을 지키면 부드러운 애니메이션을 구현할 수 있음
  • 깜빡임을 줄이는 첫 번째 방법은 “clear 후 draw”가 아니라 기존 내용을 덮어쓰기임
    • 화면을 지운 뒤 새 내용을 추가하면 빈 프레임이나 일부만 그려진 프레임이 잠깐 보일 수 있음
  • 두 번째 방법은 업데이트 내용을 표준 출력에 단일 write로 쓰는 방식임
    • 여러 번 file.write를 호출하면 부분 업데이트가 사용자에게 노출될 수 있음
  • 세 번째 방법은 Synchronized Output 프로토콜을 쓰는 것임
    • 프레임의 시작과 끝을 터미널에 알려주면 터미널이 깜빡임 없는 업데이트에 활용할 수 있음
  • Textual은 60fps를 기준으로 삼으며, 그 이상에서는 눈에 띄는 차이가 크지 않을 수 있음
  • 모든 애니메이션이 같은 가치를 갖지는 않음
    • 왼쪽에서 슬라이드되는 사이드바 같은 효과는 보기 좋지만 사용자 경험에 실질적 이득이 없을 수 있음
    • 부드러운 스크롤은 긴 텍스트에서 현재 위치를 유지하는 데 도움이 됨
    • Textual은 이런 이유로 특정 애니메이션을 끄는 메커니즘을 둘 예정임

DictView로 렌더 변경분 찾기

  • Python dict의 keys()와 items()는 각각 KeysView, ItemsView를 반환하며, 집합과 비슷한 인터페이스를 제공함
  • Textual의 레이아웃 과정은 Widget과 화면 위치의 매핑인 렌더 맵을 생성함
  • 이전 방식에서는 Widget 하나의 위치만 바뀌어도 전체 화면을 낭비적으로 갱신했음
  • ItemsView 두 개의 대칭 차집합을 사용하면 새로 생겼거나 변경된 항목을 얻을 수 있음
    • 이 연산은 C 레벨에서 처리됨
    • Textual은 CSS 속성이 바뀌었을 때 변경된 화면 영역을 찾아 최적화된 업데이트에 활용함

lru_cache와 작은 함수 최적화

  • functools 표준 라이브러리의 @lru_cache는 함수 반환값을 캐시하는 데코레이터임
  • maxsize를 설정하면 캐시가 무한히 커지는 상황을 제한할 수 있음
  • CPython의 lru_cache는 C 구현을 사용해 캐시 적중과 실패 모두에서 빠름
  • Textual에는 느리지는 않지만 매우 자주 호출되는 작은 함수들이 있고, 이 중 많은 함수가 캐시에 적합했음
  • 보통 maxsize를 1000~4000 정도로 설정하면 호출 대부분을 캐시 적중으로 만들기에 충분했음
  • 캐시를 사용할 때는 cache_info() 확인이 필요함
    • 효과적인 캐시라면 hits가 misses보다 빠르게 늘어나는 모습을 기대할 수 있음
  • 두 사각 영역의 겹치는 부분을 계산하는 intersection 메서드는 작업량 자체는 크지 않지만 수천 번 호출되어 캐싱의 이점을 얻음

불변 객체가 주는 단순함

  • Python에는 진정한 의미의 불변 객체가 없지만, tuple, NamedTuple, frozen dataclass로 많은 이점을 얻을 수 있음
  • 객체를 바꿀 수 없다는 제약은 임의적인 제한처럼 보일 수 있지만, 실제 코드에서는 도움이 되는 경우가 많음
  • Textual에서 불변 객체를 쓰는 코드는 추론하기 쉽고, 캐시와 테스트에도 유리함
  • 핵심 이유는 부작용 없는 코드를 작성하기 쉬워지기 때문임
    • 클래스 인스턴스를 함수에 넘길 때는 같은 방식으로 부작용을 피하기 어려움

Unicode 아트와 문서화

  • 기술적인 내용을 말로만 설명하기 어려울 때 Unicode 박스 문자로 만든 다이어그램이 문서 이해에 큰 도움이 됨
  • Textual의 docstring에는 영역을 네 개의 하위 영역으로 나누는 메서드를 설명하기 위해 박스 문자 다이어그램을 사용함
  • 이런 다이어그램은 잘 쓴 docstring을 대체하지는 않지만, 함께 쓰면 이해도를 높일 수 있음
  • 다이어그램 작성 도구로 monodraw를 사용함
    • Monodraw는 macOS 전용임
    • 다른 플랫폼에도 대안이 있을 수 있음

fractions.Fraction으로 레이아웃 오차 줄이기

  • Python 표준 라이브러리의 fractions 모듈은 Python 2.6부터 존재함
  • Fraction은 숫자를 표현하는 다른 방식이며, 생성 후에는 float 대신 사용할 수 있음
  • 부동소수점에는 잘 알려진 한계가 있음
    • 예를 들어 0.1 + 0.1 + 0.1 == 0.3은 False임
  • Textual에서는 화면을 여러 비율로 나누는 레이아웃에서 부동소수점 반올림 오차가 문제가 됨
    • 화면 너비의 1/3 패널과 남은 2/3를 다시 나누는 상황에서 한 글자짜리 빈틈이 생길 수 있었음
  • float를 Fraction으로 바꾸면 이런 종류의 반올림 오차를 피할 수 있음
    • Fraction(1, 10) 세 개의 합은 Fraction(3, 10)과 같음
  • 24개 문자를 7개 부분으로 나누는 예시에서 float 버전은 한 글자가 부족했지만, Fraction 버전은 전체 길이를 채움

터미널 Emoji의 어려움

  • Emoji 지원은 Rich 초기부터 계속된 문제였고, Textual도 같은 문제를 물려받음
  • 터미널에서 문자는 보통 한 칸 또는 두 칸을 차지하며, 일부 문자는 폭이 0임
    • CJK 문자는 서양 알파벳보다 두 배의 공간을 차지함
    • 가운데 정렬이나 박스 그리기 같은 기본 포맷팅을 하려면 출력될 텍스트의 터미널 폭을 알아야 함
    • 따라서 len(text)만으로는 터미널에서 차지할 폭을 알 수 없음
  • Unicode 데이터베이스에는 단일 폭 문자와 이중 폭 문자 매핑이 있음
    • Rich와 Textual은 출력하는 모든 문자에 대해 이 데이터베이스를 조회함
    • 이 작업은 가볍지 않지만 엔지니어링과 캐싱을 통해 충분히 빠르게 만들 수 있음
  • Emoji는 Unicode 데이터베이스에 포함되어도, 새 Unicode 릴리스마다 새 Emoji가 추가되어 결과가 예측하기 어려움
    • 새 Emoji를 터미널에 출력하면 한 칸 또는 두 칸으로 표시될 수 있음
    • 제대로 렌더링되지 않을 수도 있음
  • 터미널 에뮬레이터가 사용하는 Unicode 버전을 안정적으로 감지하는 표준 방법은 없음
    • 표준 환경 변수도 없음
    • 특정 시퀀스를 출력하고 커서 위치를 묻는 휴리스틱이 있지만, 테스트에서는 Unicode 데이터베이스를 안다고 생각해도 터미널이 Emoji를 예측 불가능하게 렌더링했음
  • 다중 코드포인트 Emoji는 문제를 더 복잡하게 만듦
    • 예를 들어 👨🏻‍🦰는 4개의 코드포인트로 구성됨
    • 어떤 터미널은 이를 4개 문자, 2개 문자, 1개 문자, 한 칸 또는 두 칸, 혹은 4개의 ?로 렌더링할 수 있음
  • 실무적으로는 Unicode 9의 Emoji를 쓰면 여러 플랫폼에서 비교적 안정적임
    • 새 Emoji와 다중 코드포인트 문자는 현재 터미널에서 잘 보여도 피하는 편이 나음

Textualize 채용

  • Textualize는 브라우저의 일부 역할을 대체할 수 있는 TUI 프레임워크를 만들기 위해 채용 중임
  • 채용 정보는 Jobs에서 확인할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 모든 TUI 개발자가 결국 Unicode에 부딪히고, 국제 문자와 이모지를 제대로 처리하는 일이 원래 TUI 프로젝트와 비슷하거나 더 큰 별도 프로젝트가 되는 게 재미있음
    rivo/tview에서도 같은 일이 있었고, 그 결과 만든 rivo/uniseg 패키지를 통해 다른 TUI 라이브러리 관리자들도 같은 문제를 겪는다는 걸 알게 됨
    결국 문자 폭이 표준화되어 있지 않고 터미널이 복잡하기 때문에 모두가 각자 해법을 발명함. 글의 작성자는 Unicode 9만 지원하는데, 현재 Unicode는 15.1이라 언젠가는 특정 이모지나 국제 문자가 잘못 렌더링된다는 불만이 나올 것이라 좋은 해법인지 확신하기 어려움

    • 현재 최선은 mode 2027을 감지하고 지원될 때 활성화하는 것임. 그러면 터미널이 글자소를 제대로 처리한다는 걸 알 수 있음
      이 기법을 쓰는 TUI 라이브러리 두 개를 유지보수 중인데, 이모지 지원은 거의 훌륭했음. 그중 하나는 uniseg 라이브러리도 사용함
      https://mitchellh.com/writing/grapheme-clusters-in-terminals
    • 모든 이모지를 단일 기호로 정규화해주는 라이브러리가 이미 있는지 궁금함

  • textual에 대한 가장 큰 불만은 React처럼 되려 한다는 점임. 많은 사람이 익숙한 인기 프레임워크라 왜 그러는지는 알겠지만, 사용자 인터페이스를 만드는 좋은 방식이라고 보진 않음
    반응형 설계 자체는 검증된 길이고, 잘 동작한다고 알려진 방식에 시스템 설계를 기대는 건 프로젝트 위험을 줄이는 좋은 방법이긴 함
    그런데 거기에 CSS의 변형까지 쓰는 건 지나쳐 보임. React 모델은 표준화된 컴포넌트를 선호하면서 CSS의 개념을 여러 면에서 이미 깨뜨렸고, 개발자들이 CSS로 컴포넌트를 커스터마이즈하는 건 정당한 아키텍처라기보다 React 진화의 부작용처럼 보임
    마지막으로 써봤을 때는 CSS를 써야 했고, 좋은 표준 컴포넌트가 없어 직접 만들어야 했음. 컴포넌트가 깔끔하게 캡슐화된 Python 클래스 하나가 되는 대신, 공식 문서는 리스트 컴포넌트를 만들고 외부 스타일시트로 꾸미는 식이었음
    Python에서는 어떤 일을 하는 명백한 방법이 하나, 가능하면 딱 하나 있어야 함. React를 너무 가깝게 따라가면서 JavaScript 커뮤니티의 가장 큰 악습까지 따라 하는 것처럼 보임

    • CSS를 꼭 써야 하는 건 아님. 사실 예전부터 그랬고, 모든 스타일은 코드로 설정할 수 있으며 문서에는 모든 스타일마다 CSS와 Python 등가 코드가 있음
      좋은 표준 컴포넌트가 없다는 것도 확인한 지 꽤 된 듯함: https://textual.textualize.io/widget_gallery/
    • React가 되려 한다는 느낌은 잘 모르겠음. HTML과 CSS, 어쩌면 JavaScript의 일부 개념을 쓰려는 건 분명하지만, 완전히 새로운 UI 시스템을 처음부터 배울 필요가 없어서 오히려 매우 빠르게 진행할 수 있었음
      직접 컴포넌트를 만들 필요도 없었고 CSS는 이미 알고 있었음. 오히려 약간의 레이아웃 차이와 CSS에서 벗어난 부분이 가끔 혼란스러웠음
    • 그래픽 프로그램 안에 터미널을 임베드하는 방법을 원함. 수많은 터미널 에뮬레이션을 지원할 필요는 없고 하나만 되면 되며, macOS가 우선이고 다른 플랫폼도 되면 좋음
      일반 GUI 창 안의 한 컴포넌트가 터미널 창인 형태를 상상하면 됨. 이런 게 있는지, 아니면 그냥 고정폭 글꼴 텍스트 뷰를 써야 하는지 궁금함
    • textual이 어떻게 React 프레임워크처럼 되려 한다는 건지 더 설명해주면 좋겠음. 글 어디에서도 React라는 말은 보이지 않음
    • React, 그리고 일반적인 함수형 반응형 프로그래밍이 UI를 만드는 좋은 방식이 아니라면 무엇이 좋은 방식이라고 보는지 궁금함

  • 이 TUI는 예쁘지만, 실제로 내가 쓰고 돈까지 낼 상황은 상상하기 어려움. 맞는 환경에 있지 않은 걸 수도 있지만, 내 경험상 사람들은 정말 미니멀한 도구에 만족하거나 곧바로 GUI로 사용자를 만족시키려 함
    예를 들어 글의 YouTube 링크는 셀을 강조 표시하는 표를 보여줬는데, 왜 그걸 TUI로 해야 하는지 모르겠음. 강조된 활성 셀을 이동해야 한다면 결국 다른 기능도 많이 필요해지고, 결국 제대로 된 GUI가 필요해질 듯함

    • 텍스트 UI를 선호할 이유 중 하나는 어디서나 어떤 컴퓨터에서든 빠르게 쓸 수 있다는 점임. 느린 동영상 기반 VNC가 필요 없음. 이미 터미널을 쓰고 있다면 그 경험을 개선하는 것도 좋고, 이 회사가 노릴 만큼 충분한 시장이 있음
      다만 “제대로 된 GUI”가 무엇인지는 잘 모르겠음. 터미널에는 널리 쓰이는 공개 표준이 있고, 이 프로토콜들은 어떤 GUI 프레임워크보다 더 표준적이고 상호운용성이 높으며 모든 시스템에서 지원됨
      여기에 동영상 같은 요소가 들어가고 몇몇 빈틈이 메워지면, 브라우저와 경쟁하거나 전체 컴퓨팅 경험을 터미널로 가져오는 것도 합리적으로 보임
      물론 터미널이 동영상을 추가하면 “제대로 된 GUI”의 렌더링 파이프라인을 베끼는 셈이지만, 터미널 경험을 개선하는 일이고 크게 성공하면 GUI에 UNIX식 단순함을 가져오는 것으로도 볼 수 있음
    • 예컨대 의료 청구 입력처럼 직원들이 모든 청구 코드를 숙지하고 아직도 AS400 녹색 화면 콘솔을 쓰는 업무가 있음
      직원들은 키보드 단축키로 작업해 매우 효율적이고, 누군가 AS400을 현대적인 웹 앱으로 바꾸려 할 때마다 생산성이 100배 떨어짐
      Vim/Emacs 고수와, 보기에는 매끈하지만 키보드 단축키가 없는 GUI의 차이와 같은 상황임
    • 지금은 확실히 틈새처럼 보임. 순수 명령줄보다 사용자 친화적인 무언가가 필요하지만, 어떤 이유로 웹 UI를 제공하기에는 위험한 경우라면 TUI가 맞을 수 있음
      사용자가 서버에 SSH로 접속하고 TUI 앱을 셸처럼 쓰게 할 수 있는데, 다소 억지스러운 시나리오인 건 인정함
      개인적으로 Textual은 쓰기에 조금 이상했지만 ncurses보다는 나았음. 다만 원하는 결과를 주진 못했음. 옛 메인프레임식 TUI 애플리케이션은 굉장히 효율적으로 느껴졌음
    • 제대로 된 GUI도 좋지만, 같은 일을 SSH 연결 너머로 해야 할 때는 이야기가 달라짐
      가끔은 잘 동작하지만, 예를 들어 대역폭이 큰 연결에서 X 포워딩을 쓰는 경우처럼 제한적임. 다른 경우에는 GUI가 완전히 둔해짐
      텍스트 기반 GUI가 양쪽의 장점을 가져갈 수 있어 보임

  • “첫 번째 요령은 지우지 말고 덮어쓰기”라는 방식은 DirectX 이전 게임이 작성되던 방식과 같음
    프레임 버퍼에 직접 쓰고, 전체를 지우고 다시 그리는 대신 바뀐 부분과 그 주변·아래를 다시 그림. 전체 화면을 제때 갱신할 시간이 없었기 때문임

    • 당시에는 적어도 두 가지 기법이 더 있었음
      첫째는 다른 버퍼에 쓰고, 프레임이 끝나면 전체 버퍼를 한 번에 복사해서 각 픽셀이 한 번만 바뀌게 하는 방식임. 이 버퍼는 보통 비디오 RAM이 아닌 일반 RAM일 수도 있음
      둘째는 비디오 RAM 안의 다른 버퍼에 쓰고, 그래픽 하드웨어 레지스터를 바꿔 모니터에 표시할 픽셀을 그 버퍼에서 생성하게 하는 방식임
      절충점이 달랐음. 전체 버퍼 복사는 비쌌고, 주소 레지스터 변경은 저렴했음. 하지만 레지스터 세부사항은 하드웨어 의존적일 수 있었고, 제대로 된 그래픽 드라이버 프레임워크도 없었음
      단순히 “버퍼 뒤집기”를 하려면 화면 밖 버퍼로 렌더링할 때도 픽셀을 비디오 RAM으로 보내야 했는데, 비디오 RAM 접근은 일반 RAM보다 느렸던 것으로 기억함. 사실상 NUMA 구조라 픽셀이 얼마나 자주 덧그려지는지에 따라, 마지막 복사를 포함해도 일반 RAM에서 렌더링하는 편이 전체적으로 더 빠를 수 있었음
    • ComputerCraft 프로그래밍에서 이 방식을 배웠고, 이후 여러 번 유용했으며 가끔은 업무에도 쓰였음
      다만 터미널에 프레임의 시작과 끝을 알려줄 수 있는 능력이 훨씬 더 강력하다고 봄

  • 소프트웨어 엔지니어들이 왜 TUI에 그렇게 관심이 많은지 정말 모르겠음. 좋은 명령줄 프로그램은 좋아하지만 TUI는 끌리지 않음

    • TUI는 웹을 제외하면 사실상 또 하나의 보편적으로 설치된 크로스플랫폼 GUI 도구킷임
      게다가 해커 감성이 있음. 스타일이 콘텐츠와 강하게 분리되어 있지 않고, 조정 가능한 스타일 옵션도 제한적이라 TUI 앱들은 대체로 하나의 스타일로 수렴함. 그 스타일이 해커 영화와 멋진 SF를 떠올리게 함
      기업 디자이너들이 좋아하는 영역도 아니고, 회사들이 TUI를 근거로 기업이나 소비자에게 판매를 성사시키지도 않음. 그런 상업적 압력이 없어서 TUI는 개발자가 개발자를 위해 설계함
      그래서 TUI 밈은 스스로 강화됨. 개발자들은 TUI를 보고 쓰면서 보통 개발자를 염두에 둔 도구라는 걸 느끼고, 다시 자기만의 TUI를 만들고 싶어짐
    • 취향 차이임. 그래도 앱을 SSH 너머로 실행할 수 있다는 건 큰 장점임. 나 같은 사람은 GUI 앱도 제공할 수는 있지만 보통 제공하지 않는, 빠르고 키보드 중심적인 경험을 좋아함
    • TUI를 쓰는 명백한 이점은 많지 않지만, TUI를 작성하는 데는 큰 장점이 있음. 여러 면에서 더 쉽기 때문임
      크로스플랫폼이 거의 공짜이고, 픽셀 단위로 완벽한 GUI를 만들 필요가 없으며 애초에 불가능하고, 아이콘이나 그래픽도 필요 없음. 그래픽을 보여줄 수 없기 때문임
    • 터미널 안에서 실행하면서 명령줄보다 더 많은 사용자 인터페이스가 필요할 때 좋음. 때로는 TUI가 명령줄보다 빠르고 전체 상황을 더 잘 보여줌
    • CLI를 많이 쓰지만 어떤 작업은 GUI가 더 잘 맞고, TUI는 GUI와 CLI 사이의 중간 지대임
      선호하는 글꼴을 쓰는 터미널 에뮬레이터를 계속 사용하면서 GUI 같은 인터페이스를 가질 수 있음
      지금까지 써본 TUI 앱들은 모두 응답 시간이 낮았음. GUI 앱도 대체로 빠르긴 하지만, 답답할 정도로 느렸던 앱들은 모두 GUI 앱이었음

  • Monodraw 대안으로 ascii-draw가 있음
    https://github.com/Nokse22/ascii-draw

  • TurboVision 이후에 본 거의 모든 것은 영감을 받긴 했지만 실제로는 완성도가 부족했음. 도구킷을 제대로 써보면 귀엽긴 한데 미완성처럼 느껴짐
    다르게 말하면 내가 본 많은 TUI 프레임워크가 “의견이 강한” 프레임워크였다고 할 수도 있음
    아마 내가 둔하고 창의적이지 않은 것일 수도 있지만, 90년대에 DOS에서 Linux로 옮긴 뒤로는 B800으로 작업하던 때만큼 생산적이었던 적이 없음
    이중 버퍼링의 필요성, 로컬 직접 텍스트 모드와 터미널의 차이, 이스케이프 시퀀스까지 이해하는 데 오래 걸렸을 가능성은 있음. 그래도 ncurses로 뭔가 직접 해보려 할 때마다 뚜렷한 불만족감 때문에 거의 포기했음. B800의 단순한 이상으로 할 수 있던 것과는 완전히 달랐음

    • Win16, 이후 Win32로 GUI 프로그래밍을 배웠고 시기는 WinXP로 넘어가던 때였음
      내 시야가 도시 전체만큼 가려진 건지 모르겠지만, 메시지 펌프 이후의 GUI 프레임워크들은 모두 도무지 이해하기 어려웠음
      특히 객체지향 프레임워크들이 다중 스레드 UI 문제를 실제로 어떻게 해결해주는지 이해하지 못했음. Win32에서는 메인 렌더러를 스레드에 넣고, 보조 렌더러들이 옆에서 모델을 만든 뒤 차이만 업데이트했음. 코드가 딱히 감당 못 할 정도로 커지진 않았음
    • Turbo Vision이 무엇인지는 알겠는데, B800이 뭔지 궁금함. 설마 Celeron 프로세서를 말하는 건 아닐 테고, 검색하기도 어렵고 위키 페이지도 없어 보임

  • kitty를 실행할 거라면 그것보다 훨씬 많은 걸 할 수 있음: https://m.youtube.com/watch?v=ft1Q-DwGWIs
    https://notcurses.com/

    • Kitty보다 WezTerm을 선호함. Kitty 작성자가 기능 요청이나 풀 리퀘스트를 대하는 태도 때문임
      둘 다 같은 프로토콜을 사용해 그래픽을 표시할 수 있음. 정말 그래픽이 필요하다면 터미널은 거의 올바른 해법이 아님. 다만 아이콘처럼 작은 것에는 가끔 유용함

  • 채용 중이라는 점이 흥미로움. TUI 프레임워크로 어떻게 돈을 벌 계획인지 궁금함

    • 결국 웹에서 실행하는 것도 언급했으니, 오래된 TUI를 마이그레이션하는 데 도움을 주려는 것으로 추측함. 오래된 기업용 소프트웨어 유지보수에는 컨설팅 돈이 꽤 있음
    • 그 직무들은 채워진 뒤 나중에 제거됐음: https://blog.davep.org/2024/03/28/goodbye-textualize.html#go...
    • 채용 링크가 404 오류를 냄
    • 같은 의문임. 꽤 멋진 소프트웨어를 만드는 것 같지만, 엔지니어는 비싸고 다른 프레임워크도 이미 있음

  • 참고로 컴파일되는 TUI 라이브러리 12개 정도를 평가해봤고, FTXUI가 가장 쓰기 쉽고 안정적이었음
    https://github.com/ArthurSonzogni/FTXUI
    키보드와 마우스를 모두 지원하는 대화형 대시보드를 만들기 좋은 도구임

답변달기