こうやって思いつきを書きなぐる癖はどうにかしたほうが良いもん?
ピュアな純粋培養 Unix ユーザなんて今や天然記念物だろうから、「何もしなくても工場出荷状態のまま tcl/tk をお手持ち」なんてユーザは、あんまりいないんだろう。今の Mac って Unix ベースだけどどうなの? デフォルトで入ってる? 入ってそうな気はするけどおそらくほとんどが気付かないんだろうな。つまりは、tcl/tk がいくら歴史が古くて入手が非常に容易だったとしても、これはかなり多くの PC ユーザにとっては、「いざ、手に入れん」と思うかもしくは「それへのインターフェイスを持っているなにがしか」を手に入れるかのどちらかでしか、tcl/tk に触れる機会はないのであろう。
「それへのインターフェイスを持っているなにがしか」というのは、Python であれば tkinter が該当し、Ruby なども同じ位置づけのものを持っている。Python の場合、確か記憶だと configure でデフォルトで enable になってたと思う。だから野良ビルド派も、望まない限りはビルドすることになる、だったかな確か。ただ、最近の Unix だと(embed 向けとか特殊なやつを除けば) tcl/tk はほぼ間違いなく必ず入ってるので linux のディストリビューションが「あえて tcl/tk を disable にする」ことはなく、そして公式の Windows 版 CPython も同梱するので、まぁ Python ユーザのほとんど大半は tcl/tk を手にすることになる。
で。これな、前から思ってたことなんだけどさ。
その「Unixユーザ」は当たり前に享受出来て、以外のユーザはその恩恵が限定的、な一つの事実について、なのよ。あんまり詳しいことはワタシに聞かないで欲しいんだけれど、荒っぽい理解だとね、tcl/tk って、簡単にいえば「ライブラリ(tk)とその適用(tcl)」の関係にあって、tcl が「GUI 作成できちゃうスクリプティング」なのね、だから「Python とか」にとっては tcl はいらん、tk だけでええんや、というノリになる。ので、つまり Python ユーザは「tk の恩恵には目いっぱい預かる…、のだが」ということになるわけだ。
つまり、Windows を仕事 PC に採用しており、「Python なんてリスキーなものはインストール許可しないもんね」とまでは言われていない幸運な企業において、「だけど MSYS だの cygwin なんて馬の骨ともわからんものはインストールしたらあっぶないんだぞー」とは言われている企業だったとして、なおかつ「tcl/tk? 何それ食べれんの?」ではあったとした場合。これは「tk を使う」ことと「python の tkinter を使う」ことが完全に同義語となり、この場合「Unix ユーザなら tcl が使える」のとの開きが出る。
何が言いたいの?
うん。まぁたとえば「bash スクリプトに GUI」の道が開けてしまうのが tcl のお気楽さ、なんだけれども、これは Windows ユーザにとっては結構ハードルが高くて、だからんな面倒なことするくらいなら、python だの ruby 手持ちならそこから tkinter だので tk 使ってしまえばいい、という思考の短絡をしてしまえばいい、ってことにはなる、なるんだけれど、仮に、仮にである。「tcl/tk 本体だけを手持ち」という状態を考えられる場合?
そう、「あなたの大好きで大好きで仕方がない MS DOS」で簡単に GUI を組み込める、という「夢物語」をみれるのである。
…やらないよ…。
ちなみに Python がどうやって「tk」を取り込んでいるかというと、これは「tcl/tk 本体を同梱」しているのではなくて、共有ライブラリ(C API)の形の tcl/tk (tcl86t.dll/tk86t.dllとか)とその C API へインターフェイスしたライブラリ(_tkinter.pyd とか)のセットの同梱になっているので、「世界一ステキな MS DOS」から単独で切り出して利用するのはかなり無理がある。どうしてもそうしたい場合は、たとえば ActiveTcl などをインストールせねばならんだろう。いまどきはかえって、よほどの古参でない限りは「ActiveTcl なんてどこの馬の骨ともわからんやつ」とみなされる可能性の方が高げよね、と思うわけよ、たぶん許可もらうのに Python と ActiveTcl のどっちが通りやすいって、圧倒的に前者だろう、tcl の方がはるかに歴史があるのにね。
あと、このように「DOS から」を考えると相当絶望的なんだけれど、ただこれが「C/C++ とか C# とかから」だったりするならちょっとだけ話が別で、特に「C# (とか)」は PowerShell というか .net の道につながるので、なんなら「.net から使う tk」は、「Python インストールしただけ」の状態でもそんなに非現実的ではない、ように思う。だって「tcl86t.dll/tk86t.dllとか手持ち」ですから。世界が破滅するほど難しい、わきゃぁなくて、割と簡単なんじゃないかな。入り口だけならなんとなく半日～一日格闘すれば道が開けるんじゃないかね、おそらく。(C# 経由の場合は p/invoke を使うことになる。というかまぁこれが出来るんだから C API があるなら大概のことは出来る。)
うん、やらないよ。努々楽しみになんかしないように。絶対期待するなよ。
2022-01-11期待外れる追記:
なんでなの。このネタがよく読まれてる理由が理解できん。ひょっとして「DOSでGUI」をやろうとする人が多い? いやぁ、悪いこと言わんから PowerShell 使っとけって。
で、こうしてなぜか頻繁に Popular Posts に登場してしまうと、書いてしまったちょっとした誤解も直さなきゃなぁ、て気になるわけね。
ふたつ気になってたけど、ひとつは解決しない。上で言ってる「荒っぽい理解」が正しいのかずっと不安なのだが、まぁワタシにとっては別にどっちでもいいので、正解を知りたい人はちゃんとしたとこで調べておくれ。
こうして追記しようと思った「ワタシの誤解」は Python と Tcl/Tk の歴史に関して。上で書いたのはワタシの大学院生時代(25年くらい前)の記憶で書いてたのね。その時の記憶は、当時まさに Python が「誕生したばかり」、Tcl/Tk はもう出来てしばらく経ってた、と記憶してたの。これがね、どうも違うみたいなんだ。
Tcl が 1988年、Python が 1991年、つまりたった3年しか違わないんだよね。だから上で言ってる「Tcl/Tk の方が遥かに歴史がある」は、間違いもしくは言い過ぎ。
言い訳させて。
当時さ、まさにワタシはリアルタイムで Python が人気を獲得していくのを体験しててね、そのワタシが大学院生だった 1996～97年というのは、ちょうど Python が広く認知された頃だったの。だから書籍も非常に少なかったし、ほぼ同時期(数年あとかな)に始まった Ruby の情報の方がなんなら日本では多かった。
一方で Tcl/Tk はその時期もう既に広く知れ渡り、そう、今と同じように「X Window System をインストールするのとほぼ同じマインドセットでデフォルト扱い」とみなされてた。もちろん「SunOS 4.1.3」なんて OS のプリインストール状態では入ってなかったと記憶してるけれど、そんな素の状態でなんか誰も使わんの、X Window System を入れるわけよ、その作業の中で一緒に入れてた気がする。そして当然ながら書籍も結構出てた。(というか Unix 関連の書籍で結構当たり前に紹介してた記憶がある。)
つまりこの三年の差って、1996～97年段階だとまだ結構効いてて、Tcl/Tk の認知(人気)度と Python の認知(人気)度にはかなり隔たりがあったんだよね。その頃って、はっきりいって python は「得体のしれないもの」みたいな認識をしてる人のほうが遥かに多かった。というか、大学などいわゆるアカデミックなところにいる人以外は誰も知らないものだったと思う。
そういうわけ。結論は「Tcl/Tk の方が遥かに歴史がある」は、間違いもしくは言い過ぎ。ただその誤解をしてしまったのにもワタシ固有の事情がある、てことはわかってちょんだひ。
2022-03-19今日も期待外れる追記:
たぶんねぇ、このネタに喰いついている人の一定数は、いわゆる「バッチにインチキ GUI」したい人と被ってるんだと思うんだ。
たまたま Go での UI のアプローチを探ってる中で、それ(お飾り GUI)に相応しいのを見つけたので紹介しとく。オリジナルは Zenity。GNOME プロジェクトなのかな、ワタシは初めて聞いた名前なのだが、GNOME なのなら知ってる人も多いのかもしれんね。これは(Windows 11 なら)WSL2 でもちゃんと動く。WSL の fedoraremix の場合は「sudo dnf install zenity」でインストール出来る。使い方はこんな感じ:
でこれは「GNOME のもの」つまり(普通に考えれば)Unix 用、なわけなのだが、これの代替となるものを go で書いた人がいて、それが ncruces/zenity。二つの使い道があって、オリジナル zenity の移植版も書いてくれてるのでそれをそのまま使うのと、そして「go ライブラリとして go プログラミングのおともに」する使い方、の二つ。後者の使い方はそのうち別の場所で書こうかと思っているけれど、前者の使い方(上の絵と同じ使い方ね)の場合は、(Go を持ってないならインストールして)「go install github.com/ncruces/zenity/cmd/zenity@latest」でインストール出来る。細かく見てないけどたぶんオリジナルと同じことが出来るんだろう。cgo を使わないのがありがたい。
zenity は、tcl よりもさらに限定的に「お飾り GUI」するための「クロスプラットフォームな」部品。メインがあくまでも CUI で、ところどころで対話が必要なので簡単なダイアログを使いたい、みたいに非常に軽いニーズ向け。tcl は結局はフルスペックの GUI を作れちゃうんだけれど、zenity はまったくそれを願わない用途向け。「コモンコントロールだけで GUI する」と言えばわかる? パスワード入力だけ必要だ、みたいなバッチプログラム、あるでしょう? そういうときに便利ろ? オリジナルの zenity の普及度はワタシにはあんましわからんけれど、「Unix なら zenity を入れとくれ」で済むクロスプラットフォーム性は、悪くないと思う。(ncruces/zenity は Unix ではオリジナルをサブプロセスとして呼び出すだけのラッパーとなり、Windows/MacOS ではその移植版を提供する、というノリになってる。)
