光学薄膜設計ソフトの設計 その16「インターフェイスのイメージ」

最適化を行う光学薄膜計算のユーザインターフェイスを考える上で後回しにできない問題に気がついた。普通、最適化は試行錯誤的にいろんなことを試すのであっという間に中間データだらけになってしまう。これをどう管理するか、と言う問題。

たとえば

1. 上書き（古典的ソフト同じ）
2. 履歴そのものをドキュメントとして扱う
3. 最適化前のドキュメントへのポインタを持った新規ドキュメント
4. 逆に最適化後の新規ドキュメントへのポインタを持った最適化前ドキュメント
5. 最適化前を名前で暗示した新規ドキュメント
6. 新規ドキュメントと履歴を表示する別ウィンドウ

などが考えられる。

上書き

は論外、だよな、いまさらもう。

ドキュメントが履歴そのもの

2番目のように試行錯誤の過程をひとつのdocumentにまとめた場合、履歴管理が必要になるけど、例えば何世代か前のデータをもとに違う最適化を行ったりする。その場合、履歴はtreeになる。使い勝手としてはひとつのdocumentになっていて、例えばドキュメントウィンドウには履歴がNSOutlineViewで表示されていて、ある行をダブルクリックするとそのデータが前回考えたNSTableViewで開く、というもの。どんどん最適化をいろいろ試行錯誤するにはこの方がいいけど、これは実装がめんどうだ。

それに、もし最適化ではなく手動で書き換えた場合、これでは単に上書きになってしまう。これはおかしいから、手動で書き換えた場合も、その変更履歴を残していかないと首尾一貫しない。そうすると、じゃあタイプミスしたのも残すのか、とかいろいろ面倒な問題が増える。undoバッファを使う、というのもありだけどこれはこれで大変。売り物にできるようなまじめなアプリにしたいならそれが一番いいか。

ポインタを持つ場合

最適化のたびに新規documentを作って、最適化する前がどれだったか、というポインタだけを持っていることにした場合。途中のdocumentを保存せずに閉じるとポインタの意味はその時点で無くなってしまう。これはそれぞれがdocumentとして独立しているのでどうしようもない。逆に、最適化した後の子供を保持するようにした場合。子供のNSMutableArrayを持っている。孫やひ孫はどうするか。最適化を繰り返して、途中のdocumentを消したらやっぱり親ポインタを持っている場合と同じで、ポインタの意味は無くなってしまう。ポインタを持っている場合もユーザが意識的に履歴を管理しなければならないのでそれほど役には立たない、ということになる。

ファイル名で履歴を表現する場合

名前だけを、いかにも子供のような名前に付け替えてユーザに管理をまかすと言う割り切りもいいし、それは実装が一番簡単。でも自然にかつ簡潔に履歴を名前で表現するのは難しい。

例えば名前がdocumentNameだとすると、最適化した後はdocumentName-1とかにする。最適化を繰り返すとdocumentName-1-1-1-1とかになる。これだどtreeの表現はできる。でも、普通最適化の試行錯誤は分岐よりも連続的に繰り返す方がずっと多い。だから、-1-1-1-1...だらけになってしまう。あほやな。原理的にそれ以外の名前の付け方ではtreeは（少なくとも任意深さで任意分岐のtreeは）表現できない。

独立ドキュメントと履歴表示

普通に名前を付けて、履歴確認のウィンドウを作る。それこそNSOutlineViewを使ってどう最適化してきたか、を参照できるようにする。名前はドキュメントスタイル（untitled1なんか）に任せる。履歴は表示だけで管理はユーザ任せ。名前の変更はOutlineViewに反映できるようにはする。メモリにもファイルにもない履歴は、たとえば赤字で表示する。OutlieViewに表示された名前をダブルクリックすると、メモリにある場合はそのウィンドウが最前面に来る。ファイルになっている場合は、そのファイルが読み込まれて表示される。赤字は何も起らない。

結局．．．

どれがいいか。不親切ではなく、でも実装はなるべく簡単なのとすると最後の「新規ドキュメントと履歴ウィンドウ」がいいだろう。とりあえずこれにすることにして先を進めよう。

ダミーインターフェイス

ユーザインターフェイスを具体的に思い浮かべるために、ダミーのユーザインターフェイスを作ってみた。「この画面はイメージです」というやつ（これ、英語に訳すときなんて言うの？）。
InterfaceBuilderでウィンドウを作って、ダミー表示のためのコードをちょこっと書いた。

左上にはドキュメントウィンドウが並んでいる。右上は履歴ウィンドウで、これはアプリケーションに一つだけ。左下はグラフ表示ウィンドウで、これは一つのドキュメントに対して複数作ることができて、そのドキュメントに結びつけられている。ドキュメントをファイルにセーブするときは、その表示データもセーブできるようにする。

ドキュメントウィンドウ

ドキュメントウィンドウは一つの光学多層膜を一つのウィンドウにまとめたもので、

• それぞれの層を1行で表したTableView
• その他のパラメータを入力するためのテキストボックス
• グラフ表示を作るためのダイアログを出すボタン
• 最適化のダイアログを出すボタン

などが並んでいる。それぞれの層は膜厚や屈折率のパラメータを設定したり、最適化の際に変数として取り扱うかどうかなどのフラグが並んでいる。これだと横に長くなりすぎるな。OutlineViewにするか？表示はシンプルになるけど、わかりにくくなる。このあたりの表示の仕方はもう少し練る必要がある。

グラフ表示を作るダイアログに波長域とかのパラメータを入力して、グラフを描くと、それを表示したウィンドウが開く。この中は別途進めているPlotライブラリを使う予定。

そのウィンドウが表示されている、あるいはファイルにセーブされている場合、ドキュメントウィンドウの左下のポップアップに現れて、ポップアップで選択されるとそのウィンドウが最前面に来る。

例えば、グラフ表示ボタンはオプションキーを押しながらクリックするとダイアログを出さずに前回のパラメータでグラフを書くとか、ポップアップはオプションキーを押しながら選択すると、そのときのパラメータを埋めたグラフ表示ダイアログを開くとか、そういった小さな親切は実装する必要がある。

履歴ウィンドウ

履歴ウィンドウは
最適化のたびに新しいドキュメントを作ることにしたので、その派生の履歴をOutlineViewを使ってツリーに表している。この図ではuntitledからuntitled1を作って、それから2を作って、その2をおいといて、1から3を作って、そこから4、5を作って、もう一度2から6、7を作った、と言う意味になる。

アプリケーションが立ち上がってからの履歴をすべて表示して、終了すると全部クリアする。完全に新しいデータ（0から作った、あるいは前回作ったデータをロードした）はツリーのトップレベルに並ぶ。

右側のコラムには、ウィンドウが開いているドキュメントはその名前が（従って左のアウトライン表示と重複する）、ウィンドウがなくてファイルになっているものはそのpathが、どこにも無くなっているものは空白（あるいはどこにもないよ、と言う表示）になる。この図では全部がまだメモリの上にあってウィンドウを持っている、ということになる。

計算との整合性

これまで考えてきた計算のためのクラスの構造や、最適化のための付加的なクラスと大きく矛盾するところはなさそう。もうちょっと突っ込んで考えないと矛盾点が明らかにならない、というところもある。 実装の前にもう少し詰める必要のあるところとして

• ファイルの形式
• ドキュメントとグラフ表示などの結びつきをどうするか
• 屈折率データベースの構造

が残ってるぐらいかなあ。

う～ん、全部実装するとなるとえらい大変やなあ。けどまあ、どうせやるならこのくらいしないと。いつ完成するかはわからんけど、その過程が大切、特にボケ防止には、ということで。