Readmeじゃないよ 8

■20020313

なんだかんだで、4週間ほど、MorePasteから遠ざかってた。ADSLは開通していて、なかなかのスピード。ネットワークに関しては、陸の孤島にはならずには済んだということね。でもまぁ、スピードってのは慣れちゃうもので、すでにそれが普通、って感じ。

引用符のプラグインで、履歴リストのクリアを元に戻せるようにする、ってのが、ここのところやっていたこと。1つのボタンで、状況に応じて、動作が「クリア」と「戻す」に切り替わるようにする。いくつもボタンを置けるスペースはないからね。

1つのボタンの動作が「クリア」と「戻す」の2種類あるってのに対しては、すぐにそれぞれをActionとして定義して、状態に応じて入れ替える、ってことを考えちゃう。Stateパターン的実装で、結構、常套手段。「クリア」をClearAction、「戻す」をRevertActionてな名前にして、内部クラスで定義することにした。

「クリア」の動作になっている時にボタンを押下すると、ClearActionは、RevertActionに履歴リストの中身を退避させて、リストを消去してから、RevertActionをボタンにsetActionする。逆に、「戻す」の時は、RevertActionが退避した内容をリストに書き戻して、ClearActionをsetActionする、と。「クリア」と「戻す」は、お互いにUndoの関係というわけ。

問題は「戻す」になっているときに、リストが更新されたらどうするかってこと。これはちょっと悩みどころで、結局、退避した内容を破棄して、「クリア」に戻ることにした。これも通常のUndoの履歴動作と同じ。

行けるじゃない。すっきり眠れそう。

■20020315

引用符のタブで、履歴リストのクリアをUndoする、って話の続き。

2つの状態をActionで定義したんだけど、リストの履歴の有無と、退避した履歴の有無で、どっちになるか決まる、ってことになっちゃった。こういうチェックをベタに書くのって、そもそもStateパターン的じゃないし、あんまりが筋がいいとは思えない。どうしたものかね。

ClearActionは、checkEnabledというメソッドを用意していて、これを呼び出すとリストの状態を見て、「クリア」ボタンの使用の可不可を決めるように作っている。このメソッドをRevertActionにも実装することにしましょ。で、RevertActionのcheckEnabledでは、リストの状態によって、ボタンのアクション自体を「クリア」に換えるってな処理をしてやればいい。

ポリモーフしてcheckEnabledを呼び出せるように、インタフェースを定義して。ボタンからgetActionして、このインタフェースにキャストして、checkEnabledを呼び出すと、そのときの状態に応じたチェックが実行されるというわけ。

なんか、最近、口の中が傷んでるんだよね。ちゃんと寝ないとな。

■20020323

引用符のタブとか、改行文字の設定をするタブとか、ボタン周りの気になっていた動作はなおし終わって。で、やっと、パスのタブの改修。実は、パスのが一番コードのサイズが大きいんだよね。ディレクトリのツリーの周りは、処理が込み入ってるし、あんまりいじりたくないってのが正直なところ。いじるにしても、思い出すのに時間がかかりそうだし。

どう直せばいいか、ってのは、他のタブをいじってきて、大体整理できているんだけど、やっぱり簡単にはいかない。状態を保存するために、プロパティをファイルに書き出す処理なんかは、完全な機能追加だから、結構修正しないといけないんだよね。ラジオボタンのメニュー項目の保存なんかは、ボタンの定義のしかたに影響するし。

ラジオボタンの状態の保存は、それを配列で定義しておいて、どれが選択されているか、インデックスをプロパティ値として保存することをしている。でも、以前はそんなことは考えてもいないから、当然、配列なんかにはなってないというわけ。こういうのってば、ソフトウェアのライフタイムに関係していて、先見の明がないとダメってことなんだよね。結局、いじり始めたらきりがなくなって、ポップアップメニューを組み立てる処理は、全部書き直しちゃった。なんだかなぁ。

メニューの生成処理を書き直したもう一つの理由は、更新処理のフラグ処理をなくしたってこと。今までは、リスナでフラグをセットしてから、更新処理を呼ぶようにしてたんだけど、改めて考えてみたら、別にフラグとしてとっておく必要もないし。フラグをなくしたら、actionPerformedの処理が全部同じになっちゃった。今までのってば、何だったんだろ。

最後に修正した日でソートし直す、って機能も付けて。ツリーで日付でソートしても、あんまりうれしくないいんだけどね。で、ソートとは関係ないんだけろうけど、起動時に表示されるCドライブとDドライブでは、Dはフォルダの絵になるのに、Cはファイルなってる。処理が非対称になるような理由は、ちょっと思いつかないんだけど、なんで。

■20020326

パスのタブ。いろいろと気になることが出てきて。いくつかのメソッドでは、オーバーライドして引数のパターンを複数定義している。これはこれで悪いことではないんだけど、どうも統一感がないし、統一できなかったから複数になってしまったような印象。最初に作ったときのことなんか、当然、覚えてないしね。

統一感がないってのは、ディレクトリツリーを表示するのに使ってるJTreeの枝のハンドリングで、TreeNodeとTreePathが意味の違いを見いだせずに、その場しのぎで混在しているという感じ。TreeNodeってのは、1つの親と複数の子を持っていて、そいう親子関係を保持するのが目的なんだよね。一方で、TreePathってのは、根から枝葉までの一連のTreeNodeをラップしたもので、トラバースしなくても済むようになってる。やっぱり、整理して使うべきだよな。

ということで、枝葉を引数に渡す場合は、基本的にTreePathを使うことにして、枝を切ったり、くっつけたりと親子関係の構造を変える処理になった段階で、TreeNodeを取り出すことにする。こう処理を整理しちゃうと、オーバーライドしなくてよくなってすっきりした。

しかし、TreePathを作るのに根から枝葉までの一連のTreeNodeをトラバースしているとすると、TreePathの生成ってのは、結構なコストになるはずだよな。つまり、TreePathがある場合、そこからTreeNodeを取り出して、再びTreePathを作るような処理ってのは、あんまり効率がよくないという。まぁ、今や、処理のコストなんて、よほど大量のデータを処理するときとか、サーバで動作するプログラムみたいにトランザクションが多い場合以外は、たぶん度外視ってことでいいんだろうけど。

なんか、見直しているうちに、処理上の無駄も見えて来ちゃったし、先に進めなくなって来たぞ。うーん。

■20020327

引き続きパスのペースト。パスを表示している木構造の更新をするアルゴリズムが、何となく変な気がする。更新処理っていうのは、実際のファイル、フォルダを削除したり追加したりした変更を、パス表示の木構造に反映させるためのもので、並び替えなんかの処理でも呼び出してる。

更新も、並び替えもそうなんだけど、パスを表示しているJTree上で、開いているフォルダとか、選択されているファイルとかは、表示内容を更新しても、そのままになっているように処理を書いている。エクスプローラなんかだと、表示を更新すると、選択しているフォルダのフォーカスがはずれちゃうんだよね。こういうことが無いようにしているわけ。

処理自体は単純で、更新前に、選択されてたり、開いているフォルダをコレクションにとっておいて、それを更新後、設定し直す、という仕組み。処理を追っていくと、フォルダを更新する場合では、そこに含まれるファイルやフォルダを読み込んで枝を作ってから、さらに、それらの枝がファイル上にあるかどうか、調べるような処理をしていた。実際のファイルやフォルダを読み込んで枝を作ったんだから、それが存在するのは当然。なんか、無駄な処理をしているという。

読み込んだ枝を確認することは、しないことにして、処理を書き直したら、非常にすっきりした。なんか、パスのペーストって、ほとんど書き直したような。ところで、今度は、プロパティファイルが存在しない、初期の状態で、思ってもみない大きさでウインドウが初期化されるようになった。なんでだ。うーん。

■20020330

プロパティファイルの無い状態で起動すると、ウインドウが大きくなって開くようになっちゃって、動作を調べるはめになってしまった。今までは、何で問題なく動作してたんだ?

プロパティファイルが無い、最初の起動時では、MorePasteは、Aboutのタブのイメージの大きさに合わせてウインドウを開くようにしている。プラグインをロードした際に、packする前に、全てのプラグインのPreferredSizeを調べていて、Aboutのみサイズを返すように作ったつもりだった。他のタブは、サイズを返さないから、結果として、Aboutのサイズになるというように思ったわけ。

なんだけど、調べてみたら、全部のタブがサイズを返している。で、パスをペーストするタブが最後に、大きなサイズの数字を返していた。ということで、理由はわかったんだけど、むしろ今度気になるのは、何で今まで問題が顕在化していなかったのか、ということね。なんか、変なの。まぁ、解決したから、いいか。

■20020331

3月も最終日で、明日からは4月。年度が変わります。早いことで。昼間は、なんか晴れてるんだか、曇ってるんだかわからない天気だったけど、今さっきは雷が轟き。思わず、ファイルをセーブしちゃった。セーブ中に飛ばれるのが一番怖いんだけどね。

昨日から、やっと新しいタブを作り始めていて、日付と時刻をペーストするタブ。最初は、それぞれ、コンボボックスを用意して、それぞれの形式を選択できたり、両方をペーストするか、それとも片方だけにするか、両方をペーストするなら時刻が先か、日付が先か、とかを選べるようにしようと考えてた。コンボは編集可能にして、独自のパターンも追加できるようにする、と。

でも、UIが煩雑になるんだよね。MorePasteの小さなウインドウだと、コンボをいくつも並べると、狭苦しくなるし。結局、日付と時刻を分けるのは止めにした。そもそも、どっちもSimpleDateFormatクラスに食わせるわけだから、区別できないし。つまり、日付のコンボに時刻のパターンを書いても処理できちゃうし、逆も然り、というわけ。追加されたパターンが日付なのか時刻なのか見分ける処理なんて書きたくないし、書いてもあんまり効果なさそうだし。ということで、でもそれでも何となく、形になってきた。

それと、外を歩いていて、突然、思いついたこと。そろそろ、プラグイン化に備えて、ローダクラスを外出しにする。PluginLoaderFactoryクラスから、PluginLoaderを取得して、PluginLoaderにプラグインを取り出させることにすることにした。とはいっても、作ったのは形までで、当然まだ、完全にプラッガブルにはなっていない。理想は、決まったフォルダにjarファイルとかで、プラグインを置いておけば、起動時に自動的に読み込んでくれるってのね。と、これは、すぐにはできない。

置換とかのタブまで作ったら、1.1として、リリースするかな。あ、ちなみに開発のベースは、1.3.1_03になりました。

おしまい
Mail to author Mail to author. Top of this page.

[This page was updated: 2003-03-09 ]

 

 
Copyright © 2001-2003 Takashi KOBAYASHI. All Rights Reserved.