Readmeじゃないよ 3

■990913

さてさて、先日から取り組んでいたコンビネーション機能。引用符とタブ文字変換、ボックスフィルができたので、これを一気に適用しましょう、というタグですな。組みこまれている変換処理をリスト表示して、チェックボックスで適用するものしないものを設定したり、Drag & Dropで順番を入れ替えたり、なんてことを考えている。まぁでも、順番を変えるなんてことあり得るのかね。

チェックボックスつきリストボックスは、swingをのぞいて見てもそれらしいものはなくて、ちょっと考えていたんだけど、結局自分で実装することにした。まぁ、MVCに沿った作りなんで、MのModelでチェックボックスの状態を保持するように機能を追加して、VのRendererでチェックボックスを描いてやればいい。チェックボックスの当たり判定は、当のRendererにやらせましょ。おまえが描いてるんだから、ボックスの位置は知っているでしょ、と。

問題はModelの方で、この世の中には、コレクション型のクラスで、重複を許して、インデックスでアクセスできるMapってのはないらしい。基本的にMapはキーオブジェクトと値オブジェクトの対でデータを保持して、キーの重複は許さないし、そもそも重複を許すのはListしかない。ListMapみたいなのがほしいんだけどね。内部的にハッシュ構造のリストにすればいいんだけど、どうせ実装するなら、ListとMapのインタフェースは実装したいしな。JGLにもこんなクラスはないな[http://www.objectspace.com/products/jglOverview.htm]。

と、ここまで思い始めると、簡単には作れません。そこまでしなくてもチェックボックスリストは実装できるしね。ということで、チェックボックスの状態と、リストのアイテムのEnable/Disableをそれぞれ格納するVectorを用意して、同じインデックスで保持することにした。全く、安易としか言いようがないね、この実装は。

やっぱり、なんかの拍子にインデックスがずれるんじゃないかって、ちょっと心配。その辺をaddとかのメソッドに作りこんで、そんな感じでCheckableListBoxできあがり。

■990915

コンビネーション機能の続き。一応、動作はしっかりしていて、うれしい限り。ただ、まだ、リストの順番を外から変更するインタフェースは用意していないので、引用符とタブ文字変換、ボックスフィルは、決まりきった順序でしか適用できない。やっぱり、ちゃんと用意しないとな。

コンビネーション機能を実装して、決まりきった順序でしか適用できない状況で、感じたこと。Undoができると便利ね。クリップボードのヒストリ機能なんて実装するつもりはないけど、MorePasteで行った変換処理に限って一回だけ戻せるようにすると。

やりましょう。作りましょう。要は、変換処理を行った際に、処理前を取っておけばいい。でも、どのオブジェクトにとって置かせるのがいいのかね。それぞれのタブを構成するオブジェクトは、相互不可侵だから、ほかのタブが動作したときに、Undo用のタブに指示を出す、なんてのはご法度だし。やっぱり、MorePasteのフレーム自体に持たせるしかないのかね。

この時の問題は、現在それぞれのタブは、フレームへの参照を持っていないってこと。java.awt.Componentが、getParentなんてメソッドを持ってるから、それを使えばいいのかもしれないんだけどさ。でも、明示的に設定するようにしたほうがいい、と勘が言っているぞ。そうしちゃうもんね。

さてさて、ここまでを基本機能にすることにして、これ以外のは、プラグインとして入れることにした。プラグインはBeanで提供することにしましょ。MorePasteはBeanのコンテナとして振舞うわけだ。どうなることやら。

■990918

多言語、マルチプラットフォーム対応なんて考え始めると、問題が寝られないほど発生してきて、まぁ、どこかで「この辺でいいよね」という諦めが入り始めるんだけど。ボックスフィルでの禁則処理とかワードラップの部分とか、やるならやるでこれは悩めちゃう。

そこまで本質的じゃないんだけど、どうしたものかね、と思っているのがウインドウのサイズに関する話し。「About」のタブには、イメージが貼ってあって、そのサイズにどのタブも大体収まるのだけれど、しかし、実際にウインドウのサイズをイメージのサイズに合わせて設定するのは結構難しい。サイズを一定の初期値として用意できればいいところなんだけど、そういうわけにいかないし。

理由はPluggable Look and Feelに拠るところが大きくて、タイトルバーの高さから、ウインドウの縁の幅まで、少なくとも今の時点じゃわからない。何も設定せずに作っているから、MetalのUIに固定、というつもりにすることも出来るけど、それじゃJavaらしくないし。タブを描画しているJTabPane以外の部分については、それなりに部分ごとのサイズの算出のしかたは分かっているんだけど、肝心のJTabPaneについてはなんかよくわからない。うーん。

サイズについては、あきらめて。全体を眺めて、ちょっと、構成を変えることにした。その話しは次回。

■990923

ちょっと遅い、夏休み。日ごろ酷使している目を休ませようと、3,4日、マシンに向かわなかった。でも、その間にたまっていた本をまとめて読んで。結局変な姿勢で読んでいたのが悪いのか、肩のコリは、それはそれでひどくなっちゃった。

もどってきた今日は、構成の変更の話しをすると、やっぱり、コンビネーション機能の見直しがちょっと大きい部分。今までは、コンビネーションは、引用符とかボックスフィルとかとは内部の処理オブジェクトを共有していて、それを連続的に呼び出す、という仕様だった。この場合の問題は、処理は呼び出せてもタブの方は呼び出していないから、タブの提供する機能、たとえば引用符のヒストリ登録だとかは呼び出せなかった。下手をすると引用符の処理オブジェクトとタブで引用符の中身が食い違う、なんてことがあり得たわけだ。

それで、その辺りを解決するためにとっていた策は、タブが切り替わったタイミングで発生するChengeEventを拾えるようにリスナー登録する、ということ。これはタブを切り替えただけで引用符が登録されたりしちゃうんだけど、まぁ、食い違うよりはいいよね、という感じ。でも、これだって動作があんまり分かり易くない。ただでもさえ、動作が明白じゃないって、クレームつけられてるのにさ。

それで、これを変更することにした。コンビネーションは、内部の処理オブジェクトだけを共有するんじゃなくて、タブ自体を登録するようにする。こうすると、タブが単独で動作するのと同様に処理できる。内部の処理オブジェクトの呼び出しと、タブの設定変更をバラバラに呼び出していたのを何にも意識する必要がなくなる。さらに、今までタブの内部処理オブジェクトしか登録できなかったわけだけど、それがタブなら何でも連続処理できるようになったから、今後作ったものはまぁ、なんでも登録できる。Undoのタブなんか途中にはさんだらどんな風に動作するのかね。ちょっと、想像つかないけど。。

この前から、JavaBeansに関する書籍を読んでる。Beansを作る、っていう記事はいっぱい出てるけど、Beansのローダを作る、っていうのはない。結局、BeanBoxとかのソースコードを読むしかないのかね。ゆっくりやることにするかな。

おしまい
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.