Textual - Python向けの高速アプリケーション開発フレームワーク
(github.com/Textualize)- Textualは、シンプルなPython APIでクロスプラットフォームのユーザーインターフェースを作成し、アプリをターミナルまたはWebブラウザで実行できるようにするフレームワーク
- APIはモダンなPythonとWeb開発の進化した要素を組み合わせており、分離されたコンポーネントと高度なテストフレームワークによって長期的な保守性を支援する
- ウィジェットライブラリは、ボタン、ツリーコントロール、データテーブル、入力、テキストエリアなどを提供し、柔軟なレイアウトシステムと定義済みテーマも備える
- 内部的には非同期フレームワークであり、必要に応じてasyncライブラリと統合できるが、asyncの使用を強制しない
pip install textual textual-devでインストールし、python -m textualでデモを実行できる- インストールせずに
uvx --python 3.12 textual-demoで textual demoを実行でき、この方法にはuvが必要
- インストールせずに
textual-devパッケージは、別のターミナルからアプリケーションに接続する開発コンソールを提供し、システムメッセージ、イベント、ログメッセージ、print出力の確認をサポートする- Textualアプリはファジー検索対応のコマンドパレットを提供し、
ctrl+pで開いて、アプリケーション向けのカスタムコマンドで拡張できる textual serve "python -m textual"でTextualアプリをWebに配信でき、Textual Webはローカル配信に加えてアプリケーション配信をサポートする- Textualアプリはシステム要件が低く、Pythonが動作する場所ならインストールでき、デスクトップ環境を必要としない
1件のコメント
Hacker News のコメント
今いちばん気に入っている Textual のデモは https://github.com/1j01/textual-paint
ターミナル上で動く、かなりよくできた Microsoft Paint クローン
新しい Python プロジェクトを作るとき、最初に入れたものの一つが https://github.com/Textualize/rich だった
ターミナル出力を見栄えよくするのがとても簡単なので選んだ
一方で Rich は素晴らしく、開発の流れをとてもスムーズにしてくれる。太字、色、絵文字、表といった機能をすぐ使える優れた API がある点が良い
かなりよさそう
以前勤めていたトレーディング会社で、重要なプロセス用のテキスト UI を作る際に lanterna（https://github.com/mabe02/lanterna/tree/master）を使っていた。更新された市場データを受け取り、前の取引セッションと今日の間で変わったもの、たとえば銘柄名の変更（PCLN から BKNG）、時価総額の変化によるカテゴリ変更などを処理するプロセスだった
リアルタイムシステムでは処理しないが、頻繁に起きすぎる、あるいは手作業で処理するには厄介な作業だった。会社にはトレーディング担当者向けのデスクトップ UI はあったが、サーバー UI という概念はなく、サーバーはヘッドレスだった
フロントエンド開発者はおらず、バックエンド、システム、データ系のプログラマーがたまにフロントエンドに触る程度だったので、Web UI は非常に単純か特定用途に特化したものばかりで、共通ツールもなかった
2023年だったら create-react-app や next.js のほうを選んでいたかもしれないが、オンコール中にテザリングした 4G のひどい SSH 接続からでも簡単にアクセスしたかったので、X11 フォワーディングや RDP は除外した。そこでプロジェクトの言語である Java で使える TUI ビルダーを探した
Lanterna がよかった理由は、Swing ベースの実装 があり IntelliJ からそのまま動かして素早く反復開発でき、運用環境ではサーバーのあるマシン上で SSH 経由でターミナル実行できたから
Textual も引き続き追いかけて、何かよいものを作れるか見てみるつもり。今でも Web アプリは、ブラウザではない TUI やデスクトップ GUI で作った機能的に同等な製品に比べて、結果を得るまでの労力が大きい感じがしてあまり好きではない
残念ながら、「高速なアプリケーション開発」という言葉はライブラリ自体にも当てはまるようだ
隔週で新リリースが出て、やや予測しにくいところで壊れる。Textual で プロトタイプ を作るのは簡単だが、その後の保守は難しい
ただ、まだ 0.x バージョン の間は、よりよいアプローチが明らかになった領域で少しずつ方向転換できるという利点を最大限活用している
新しいリリースを出す際には、破壊的変更をできるだけ目立つように知らせるよう努めている。回避が難しい部分や、再び動くようにするのが難しい部分があれば、GitHub issue、Discussions、または望むなら Discord でも助けを求められる
Python をそれほどやり込んだ開発者ではないので聞きたいのだが、これを大きな依存関係なしに バイナリ にするのはどれくらい簡単なのだろう
Windows と Linux 向けの製品インストールパッケージを作るのに役立つものを探している。顧客がソフトウェアをインストールする前後に、INI ファイルの書き込み、DB 接続確認、HTTP サーバー確認といった設定作業が必要になる
よさそう。ちょうど unicurses と Python で社内向けの DevOps および変更管理アプリを作ったところで、動きはするが拡張性はあまりよくなさそう
最初は TK と QT を試したが、どちらも初期セットアップに癖があった。QT はきちんと動くものの、有用なドキュメントが不足気味だった
Textual は要件にぴったり合いそうなので、ぜひ試してみるつもり
ざっと見て https://textual.textualize.io/tutorial/ と https://github.com/Textualize/textual/blob/main/docs/example... を確認した
Go では何をうまく使えたのか気になる。Textualize が魅力的なのは、かなり Web ブラウザっぽい感じ があり、スクロール可能な表ビューまできれいに扱えるから
tviewも興味深そうだが、たとえばbrew install dbuiを見ると、宣言的でネストしたナビゲーションというより、if KeyPress.A: do_something()のような命令型の処理を直接書く感じが強いおそらく「すべてを制御する」アプリケーション中心／SPA 的な見方と、「ページにコンポーネントを追加して流れに任せる」ドキュメント中心の見方の違いかもしれない。この一覧の項目についてのフィードバックが気になる: https://codeberg.org/tecras/awesome-go#advanced-console-uis
if KeyPress.A: do_something()のような命令型の処理を直接書く」というのは、最近の流行のように メッセージループ を隠さず、実際に制御させてくれるという意味？https://github.com/gizak/termui
Lazarus/Freepascal が正解。ほかは退化に近い
こういうアニメーションや遷移効果は、純粋な ASCII テキストだけで実装されているの？
真面目に言うと、「easing」と遷移機能は一度見てみる価値がある。500ms 程度の遅延は熟練者には邪魔だが、アプリ内ナビゲーションを覚えている間に文脈を提供するには役立つようだ
こういうプロジェクトはどうやって継続しているのか気になる
このプロジェクトは2年目の開発中だが、収益源が見当たらない。開発者たちは何らかの形で報酬を受けているのだろうか
https://www.willmcgugan.com/blog/tech/post/from-open-source-...
市場も考える必要がある。2023年にターミナルウィジェットライブラリを使うためにお金を払う人は、文字通りほとんどいない