日付：2002/9/5
GMail-Part3GMail開発中に記録していた「日々の作業」の続き
ーーー
2/1 送信箱の名前を日本語にする。またこちらは各フォルダのなかのメール数を表示するようにする。
どうかんがえても他のブラウザに比べて遅い。あれこれテストプログラムを作ってテストを行う。Dateをデコードするのほうが、ファイルの作成日付をみるより早い、ということを知りびっくりする。
あれこれやったあげく効果があったのは、insertTextをsetStringに変更したことだった。しかしこれ以上早くはならんのかなあ。。。予想外の発見として、htmlを簡易表示できることがわかった。RTFとかいうファイルフォーマットを使うことで。。
[注釈]
元々OMEでは送信するメールが入っているフォルダーは"OutBox"という名前になっているし送信済みのメールは"Sent"というフォルダに入る。この名前はきちんとした物だけど、日本人にとっては「送信」とか「送信済み」のほうがなじみがいいではないか。ということで表示されるフォルダの名称だけを日本語に変更した。このことからも分かる通り私はGMailの英語版とかドイツ語版というのは全然考えていないのである。Cocoaにはそうした多国言語対応の仕組みというのが組み込まれているのだが、今のところそれを使うのがいつになるのか見当もつかない。
このころから日々GMailを使ってメールを読み書きしていたので、その「遅さ」が気にかかりあれこれやっている。メールのタイトル一覧には受信の日付が表示されるが、この「受信日付のフォーマット」というのは実に多岐に渡っており、その解釈にJavaのライブラリを使っている。ひょっとするとこの処理が遅いのかもしれん。他に方法はないかと考えれば元々OMEはFinder上でメールを閲覧するための仕組みだからメールに対応するファイルの作成日付が受信日付になっているのであった。
なーんだ。ファイルの作成日付を観れば早いじゃないか。そうだよね。日付の解釈という処理を２度やっちゃいけないよね、と思い変更してみるが早くなった気がしない。時間を計ってみるとなんと日付解釈をそのたびやるほうが早い、という結論がでてびっくりした。こう書いていても
「そんなことあるか」
と思うのだが実際そうだったからしょうがない。
次にはテキスト表示エリアにメールのデータを表示する方法を変えれなんとかなるかな、と思いあれこれやってみる。するとhtmlメールを表示するときにRTF(Rich Text Formatだと思った）として扱うとそれっぽく表示されることに気がつき「Html簡易表示」などという機能として扱う。しかし所詮これは邪道のやり方であり、HTMLをちゃんと表示できるようになるにはまだ時間がかかったのであった。
2/2 会社から帰りの電車の中で「ひょっとするとファイルを開く以前に時間がかかっているのではないか」と思いつく。あれこれさぐっているうちに
・選択を変更した途端、未読に変えていること。
に気がつく。そういえば、メーラーは開けて１秒たったらとかだった。その処理を外す。次に新しくファイルを開く前に、テキストをクリアしていたのだが、全部書き直すようにしたからこれも不要。この一行を外しただけでほぼ実時間で動くようになった。感激。
早く動くのがあまりにもうれしくてそれから数十回はカーソルの上下をやってしまった。
[注釈]
このころは少し暇さえ有ればiBooｋを広げあれこれやっていた。どこかに行った帰りの地下鉄で思いついたのがこのアイディア。それまではメールの題名一覧リストで選択されたメールをカーソルキーでてててと変更するのが実に遅く
「いや、これでも結構早いよ。あ、ほら早かった。今遅かったのはきっと後ろで何かの処理が動いていたのだ」
と自分に何度も言い聞かせていた。ところがちょっと処理を変えただけで、そうして自分に嘘をつかなくても実に快適にメールを一覧できる。地下鉄の中でただひたすらリストを上下させている人間というのは端から見れば異様だっただろうが私は幸せだったのだ。しかしその幸せは長く続かず、処理速度との戦いはまだまだ続くことになる。
2/3 名古屋に往復。その新幹線の中でひたすらアドレス帳のグループ機能を作る。Groupとアドレスでレイアウトを大幅に変えなくちゃとおもっていちいち構成要素を外したりつけたりするのか。。と思ったいたら、Tabviewが使えることを発見して一気に話が簡単になる。
思ったより早くアドレス帳ができたので、今までほったらかしにしてきた「送信画面」の修正にうつる。頭の中で「これはかっこいい」と思った画面を実際作ってみるとろくなものにならない。
[注釈]
私はとにかく新しいウィンドウだのダイアログだのを開くのがとてもいやになっていたので、アドレス一覧リストの下に、選択した項目の詳細を表示するようにした。修正もそこでやるわけだ。
さて、アドレス帳にはいくつかのアドレスをまとめたグループも登録できるようにしたい。ただしそれをやろうとすると項目を選択するときに表示される詳細の内容がごろりと変わるわけだ。それをどうすんべえと悩んでいたのがそのとき。
ここで書いたようにTabViewというものを使えば比較的簡単にできる（それまではグループと個人の時で画面の部品を全てとっかえひっかえしなければならないかと思っていた）と考えたのもつかの間。このグループの処理というのは結構大変であることに気がつく。しかしとりあえず動くようになったところで操作性の向上もなんのその、私は「ろくに動いていない」送信画面の作成に突進していったのだ。結局アドレス帳のグループ編集機能は未だにろくなものではない。
2/4 会社で仕事もないのにひたすら残業。その間なにをやっているかと言えば、メールプログラム作り。
あれこれ試行錯誤の末、ようやく送信画面ができあがる。しかしまだ直接アドレスを編集できない。アドレス帳からもとりこめるが、削除ができない。作ってみるとあれこれおかしなところに気がつく。
かえってやおらアドレス帳を「設定」のタブから移し出す。
[注釈]
というわけで送信画面を作り出すのだがこれが一筋縄ではいかない。アドレス帳をせっかく作ったのだから、そこからボタン一つでアドレスを指定出きるようにしたい。複数アドレスの指定も必要だ、そんなことをずらずら考え出すと普通のメーラで横に並んでいるアドレスがなんとなくおかしく思えてくる。複数のアドレスを並べるのなら縦に並んだリストにするのが筋ではないか。
そんなことを考えて画面をあれこれ。いっそのこと宛先と写しのリストを横に並べてやろうかとも思ったが過激すぎると断念した。ついこないだ作ったばかりのアドレス帳と同じような機能を送信画面にも組み込む。ええい、面倒だ。もうちょっと楽な方法はと思うが、このころは考えるより「とにかく作ってしまえ」モードにはいっているのであった。
それが一段落すると、それまで「設定」の引き出しにアドレス帳を入れていたのがなんともいえずおかしく思えてくる。アドレス帳はアドレス帳。設定は設定だ。さーて引っ越しだと思うのだがこれも（この後何度かやったが）簡単にはいかない。
2/5アドレス帳を別のDrawerに移す作業。会社についたところでほぼ完成。ただしdelegateを移し替え忘れていて動かないことが２度。頭にきてアドレス帳から発信機能を付ける。Drawerが増えてきたので、前から考えていた「一つDrawerをだしたら他のDrawerを引っ込める機構」を追加。
[注釈]
Interface Builderというプログラムを私は大変気に入っている。今までこうした「画面上で自由に部品のレイアウトができます。」という製品をちゃんと使ったことがなかったが、このプログラムだけは使い続けている。
このプログラムを使って配置した画面部品とプログラムを結合するためには、画面の上で画面部品上からマウスをドラッグし、ずーっと線をひっぱってプログラムを示すアイコンの上までもってくる。すると首尾良く結合される。
さて、ではある部品の固まり（この例でいけば、作ったアドレス帳）を別の部品の上（新しく作った引き出し）の上に移動させようとするときにはどうするか。ぐいっと移動はできないのでまとめてコピーペーストすると見事に移動できた！ところが忘れてはならないのは、形の上では移動できたように見えても、プログラムとの結合が切れている点だ。
この切れているというのはどうにも見逃しやすい。だって観ただけじゃわかんないんだもん。というわけで思いも寄らぬところで動きがおかしく、自分の愚かさを呪いながらつなぎ直すことがしばしばだ。ここでdelegateがどうのこうのと書いているのはその「気づかなかった結合切れ」のせいなのだが、経験したのはここが初めて。しかしもちろん最後というわけではない。
2/6 朝父にメールを書く。２通のメールを参照しながら書く必要があったのだが、この左右ならべて書く、というのは結構便利ではないかと自画自賛する。
今まで返信のアイコンと引用して返信のアイコンが同じだったのをとりあえず変えてみる。ただしアイコンだけみてもどれがどれやらわからない。
アドレス帳でいくつも問題は残っているし、削除機能をつけていないのだが疲れてしまい指が動かない。しかたないからあまり悩まなくてもいいはずのConnectionSetting画面を作り出す。悩まなくいいのだが、とにかくあこれ書く必要がある。しかしここは手を動かせば進捗があるはずだ。
というわけで、項目数の多さに半ばいやになりながらなんとか作ってしまう。一発でいくかと思えば、プロトコルの選択があった。これもやんなくちゃ。
でもって通信の設定も行えるようになる。送信がうまくいかないと思い試験をしようとおもったら、Ccに自分がはいってしまう。頭にきて先延ばしにしていたアドレスの削除機能を付ける。
なぜか送信ができなくなる。よくみたら、ファイル拡張子の変更にともない、送信ファイル名の識別方法が間違っていた。任意の送信アドレスを入力できるようにしようとあれこれやるがうまくいかない。正確に言うとうまい方法がおもいつかない。ダイアログ、ウインドウを極力排除するのもここらへんかもしれない。
[注釈]
意味のとりにくい文がだらだら続くが、仕事のストレス発散に狂ったように画面を作っていたのではなかろうか。この日は平日で立派な出勤日だというのに。全く会社で何をやっているんだか。
2/7
朝昨日の晩思いついた「返信Drawerが開いている時には別の返信は行えない」ようにするため、ちょっと改良を加える。こう考えるとNSToolbarって便利だなあと思う。でもメニューからの選択もブロックしなくちゃいけないんだ。面倒。
帰る途中に、メールアドレス編集画面のアイディアを考える。適当に設定。これまで「宛先」「Cc」をボタンにしていたのをやめ、別のボタンをつけることにする。
帰ってあれこれ。なんとか手動でアドレス設定もできるようになる。
[注釈]
引き出しに送信メールを書く画面をそっくり入れるというのは今回のGMailの売りの一つである。（他の人が売りとおもってくれるか、間違いと思うかは別として）しかしそうなると「送信メールを書いている間はやってもれっては困る処理」というのがいくつかでてくる。引き出しは一つだけだから一度には一つしかメールを書くことができない。送信メールを書いている間に「新規メール」とか「返信」とかやられては困るわけだ。
困るので有れば実行不可能にしておく必要がある。幸いにもツールバーに並べたボタンを使用可能・不可能にする仕組みがそなわっており、それを使えばいいことが分かる。わーい、すごいぞ、と思ったのもつかの間、同じ処理をメニューからも選択できるようにしていたのであった。
送信メールの画面配置をまたもやいじくり回しています。実はまだいじっています。
２／８ TextViewのサブクラスを作り、キーに対しての反応を追加することを考える。しかしまずNSCustomeViewに切り替えるところでレイアウトががたがたになる。次に結構面倒だ、ということがわかる。XBrowserのソースを参照するが、これは大変そう。とりあえずメールの移動は矢印キーでもできるからいいや、と思って後回しにすることとする。でもなあ茄子みたいにスペースキーでどんどん送っていけるといいのだけど。
残った最後の懸案（今おもいついているものの中では）の送信待ち、および下書きメールの処理についてあれこれ考える。結構面倒なので、場合分けをめずらしく紙の上で実施する。
それに従ってプログラムを少し書いたところで時間切れ。
[注釈]
ずっと頭にあった「キー操作」で次のメールを読んだり、今読んでいるメールをスクロールする、という処理に取り組み出す。これが結構やっかいなのであった。
問題は「キーをおしたというイベントをどこで受け取るか」である。一つのアプリケーションでキーが押されたことにより発生したイベントは全て一カ所を通ってくれれば問題ない。しかし不幸にしてどうにもやりかたがわからない。Mac OS Xのメーリングリストにも同様の質問があったことから要望はかなり多いと思うのだけど。
最後のパラグラフで何をいっているかといえば、例えば「送信待ち」フォルダに入っているメールに対して可能なのは編集する事。「下書き」フォルダに入っているメールには編集、もしくは送信待ちに移動が可能、という処理を可能にするだけの話なのだが、何をそんなに悩んでいたのだろう。
注釈