華和梨開発ツール再考†
http://www3.to/TinyPalace/
http://kemonomimisippo.hp.infoseek.co.jp/
http://happygame.hp.infoseek.co.jp/
http://d.hatena.ne.jp/satos/
http://d.hatena.ne.jp/suikyo/20050226
これってなに？†
華和梨の開発ツールがCUIなのがどうかという問題提起のまとめと解決案を考えるページ。
……って、わしAYAユーザーやなかったっけか*1……
現状の問題点†
デバッグツール（幸水）がCUIしかない†
- AYAの玉はGUIっぽいですが実は操作体系はCUIなのでいっしょです！
- 里々はさとりて……でしたっけ。
ゴースト辞書全体を読み込んで精査という使い方はできなかったはず。できるそうです。
使ってみました。やっぱり見た目はGUIですがCUI臭さは抜けてない気もします。
ログのリアルタイム表示ツールがない†
- 設定ファイルをいじらずにこのアプリ立ち上げればログが見られますよっていうのはすごく気楽で良い。
- デバッグモードをONにしたままほったらかしてリリースしちゃった！という情けない問題。
※うちが今まで散々やってしまったアホなミスです orz
- AYAは玉、里々はれしば。
問題点の検討†
デバッグツールがCUIしかない†
- そもそもどのSHIORIもないかCUIしかないかどちらか。
- トライ＆エラーでやる人が多く、デバッガもどきを持ち出すのは
非常に稀。 <- 櫛ヶ浜やぎさん@さとーさんの日記
- 需要の低いシロモノをGUI持ち出してまで飾り付ける必要があるのかなぁ？
- 結局は掘り下げれば見た目の違いでしかないんじゃないかと思いますけれど。
いやま、これから使おうって人はかなりの割合を見た目で選ぶことになりますし、スルメのように噛んだら味が出て来る……とかいうツールは比較的不利であります。
ログのリアルタイム表示ツールがない†
- 華和梨のログ吐きはofstreamを使って生で書き出しているだけ。
- ……つまり、ostreamを継承したクラスとか作れればいける……のかな？operator<<はvirtualでしたっけ？
- WM_COPYDATAをログ取りアプリのウィンドウにSendMessageで投げつけるだけのはず。シンプル。
- 受信側はさとりてなり玉なりの互換ならそれでよろしいかと。
- GUI／CUIに拘りませんが何か各SHIORI共通でリアルタイムログ送信規格みたいなの作ってみませんかね？
とりあえず†
- デバッグツールは……まぁ、幸水そのままでよかろうと。
- 華和梨側の対応が……ostreamもどきクラスを作る工数・難易度etc...
- 華和梨のソースはばっさり環境依存部分と非依存部分を分けたファイル構成で、ログ吐き処理は非依存部にあるくせにログ送信処理はおもいっきり環境依存なので、ツールにまるなげする処理をどこに置くかが難題。
- 文字コードの問題。れしばが受けられるデータ（文字）の制限は？華和梨側で変換かまさないと駄目？玉はそのへんの対応コードあるみたいですが。
- いちばん面倒でないのがコンソールれしばもどき。ログ表示ツールなんぞGUIとかCUIとか以前にインターフェース自体要りませんからね。流すだけ。
- UNIXのteeコマンド使う時みたいに、あわせてファイルに保存できるとなおよい。
適当仕様メモ†
- Mutex "shiorilogmutex" があればログ処理アプリが立ち上がってるものと判断
- FMO "shiorilogfmo" にWM_COPYDATAでまるなげしてもらいたいHWNDを書いておく
- どうせ簡易仕様なので、数十バイトくらいのFMO作ってunsignedで表現したHWNDを書くだけとか。あまり重い仕様はダメ。
- 今後の64ビット対応は？->そのためにテキストで書く。バイナリ形式にはしない。
- ログ処理はEditコントロールかコンソール流用か。
- Editの腹が立つ32KB制限……
- コンソール流用したらまたCUIか！とか怒られそう。ログ表示するだけなのでインターフェースもへったくれもないから見た目の問題なんだけどなぁ。
ツッコミ†
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
