Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/hkoba/tcltk-gui-starters-ja
Collection of skeletons to write Tcl/Tk + snit based GUI Apps.
https://github.com/hkoba/tcltk-gui-starters-ja
Last synced: about 2 months ago
JSON representation
Collection of skeletons to write Tcl/Tk + snit based GUI Apps.
- Host: GitHub
- URL: https://github.com/hkoba/tcltk-gui-starters-ja
- Owner: hkoba
- License: bsd-3-clause
- Created: 2015-09-13T03:00:34.000Z (over 9 years ago)
- Default Branch: master
- Last Pushed: 2015-09-13T04:48:17.000Z (over 9 years ago)
- Last Synced: 2024-11-29T05:32:43.846Z (about 2 months ago)
- Language: Tcl
- Homepage:
- Size: 141 KB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# tcltk-gui-starters-ja
Tcl/Tk と snit で、サーバー作業用の GUI アプリを
雑にでっち上げたい時のための、
雛形になりそうなスクリプトをここに集めて行きます。## お断り
### 今さら Tcl/Tk、したいのですか? 本当に?
今の時代に Tcl/Tk を使って新たにアプリを書き始めることは、
時代錯誤とみなされるリスクがあります。あなたがこれから作ろうとするものが、果たして本当に Tcl/Tk で書くべきものか、
トレードオフを自分で判断できる人だけ、この道をお進み下さい。### あくまで hkoba 流です
残念ながら、私は長く独りで開発を続けていたため、
コミュニティ界隈・他の現場の事情を全く存じ上げません。ですので、ここで私が書くものは、今現在の私が知る範囲ではこう、
という程度のものです。〇〇の方が良いのでは?という意見をお待ちしています。# 一覧
これから徐々に足していきます。
* [その1](01/snitex1.tcl) Snit + BWidget
まだ一個だけですよ…
# 技術の選択に関して、その理由
## Why Tcl/Tk (still)?
確かに、Ruby/Python/Perl/PHP ... など他の LL よりは
制限の多い言語ですが、それでも bash で頑張るよりは、以下の点で遥かに
マシだからです。* ちゃんと例外処理がある。
* テストが書きやすい
* イベントループが言語組み込み
* 言語自体がシリアライザに基づいているので、メタプログラミングや、
リモート処理が容易
* 他の LL と比べて、文字列の quote が不要なケースが多い分、色々と雑に書きやすい。
* ちょっとした GUI が必要になった時に、大騒ぎしなくて済む。### Why not use Tcl/Tk everywhere?
私は Tcl/Tk で全てを書くことには賛同しません。
大抵の技術には『スイートスポット』というか、
それが一番輝く働き場所があります。例えば、ファイル操作や外部プロセス呼び出しは Tcl/Tk で書くより
Zsh で書いたほうが遥かに短く、楽に書けます。
言い換えれば、最初から Tcl/Tk で書くことは
Zsh で書くよりもコストが掛かります。
もしそのコードがどの程度使われるか分からないなら、
プロトタイプは Zsh で書いてしまって構わないと私は考えます。同様に、Tcl/Tk は本質的に入れ子データ構造の操作が弱い上に、
Perl の "use strict"/"use fields" に相当する静的検査も欠けています。
ですので Tcl/Tk で大きめの、長期間、進化を伴いながら使われるソフトを
書くときには、他の LL 同様、大量のテストコードを書く必要があります。
そのようなケースでは、私なら Perl を選択します。
(もしかしたら、今後は OCaml に移行するかもしれませんが…)要は適材適所をお忘れなく、ということです。
### I heard Tcl is a bad language. Is it still true?
* global, global!
* 可変長引数の扱い
* 無名関数
* No Scope::Guard, really?### So, what is remaining weakpoints of Tcl and Snit?
* 木構造(の葉要素)を表現する方法が標準化されていない。
Tcl の list は一見、木構造を自由に扱える良い仕組みに見えますが、
残念なことに、『葉要素』に関する定義がありません。
これは任意の部分木が、葉であるか、internal node であるかを
判定する方法を、言語が用意していないことを意味します。後は察して下さい。
* 上記の理由により、Tcl で複雑なデータ構造を扱うには、
Tcl の namespace 自体を使うしかない。ですがこの方法では、
GC が不可能になります。
(幸い、Tk の場合は widget の木構造を活用できるため、実害は少ないが)## Why Snit?
Tcl には OOP のための枠組みが複数ありますが、
私は以下の理由で Snit を使っています。* Pure Tcl かつ Tcl 8.4, 8.5, 8.6 をカバーしているので、導入に困らない
* delegation ベースの部品化
* Tk の組み込み widget と同じ API を持った widget を自作するための支援が
しっかりしている。
* どんなクラスにまとめたら良いか悩むものでも、
とりあえず snit::macro で部品化出来てしまう。